Coding Agent 上线前先要能被量：阿里云 Pilot 用轨迹回答四件事

Coding Agent 上线前先要能被量：阿里云 Pilot 用轨迹回答四件事

阿里云原生社区 2026-07-23 的文章介绍开源组件 LoongSuite Pilot。它要解决的不是再做一个编程助手，而是本机上的 Coding Agent 几乎量不到：每人每天用了多少 Token、哪类任务做砸了、一次会话改了几十个文件时链路在哪。文章把这写成经营问题。月花费可以到数万甚至数十万，却说不清值不值。

传统监控看见的是请求，不是决策

困难分三层。一次任务常常超过 10 轮 ReAct（推理、调工具、再看结果的循环）。每一轮都有模型调用和工具选择。传统指标、日志和 Trace 只能看到一串互不关联的 HTTP 请求，还原不出这棵决策树。第二层是数据天然碎：Cursor 在一处，Claude Code 在另一处，格式和粒度都不一样，横向比较几乎做不到。第三层是端侧死角。现有探针面向服务器，不管是主机上的 LoongCollector，还是 Python、Go、Java 的语言探针。Coding Agent 跑在开发者自己的电脑上，痕迹留在 IDE 历史、本地 SQLite 和 Session 日志里。

适配 Agent，而不是要求 Agent 适配你

文章给出五个取舍。

第一，不做「一个 Agent 一个抽取脚本」。生态几个月就会多出新工具，单点脚本维持不住。Pilot 用一份部署覆盖本机已安装的 Agent，每个 Agent 的探测路径、部署方式和采集配置写在 agents.d 的 JSON 里。文中的 claude-code 示例用 hook，事件包括用户提交问题、工具调用前后和停止。加一个新 Agent，主要工作是读懂它的数据格式并写转换，不改框架。

第二，端侧产品是别人的闭源程序，不能往进程里注入，也不能要求每个厂商先提供统一遥测接口。原则是采集去迁就 Agent 本来怎么落数据。五类基类对应五种增量策略：支持 hook 的读 JSONL（Cursor、Claude Code、Codex）；IDE 插件类轮询历史文件；自带数据库的用 SQLite 的 rowid 游标；只留 Session 文件的做文件轮询；命令行类则转发已有遥测日志。新 Agent 选定基类，实现两到三个方法。本地断网、重启、终端关掉都是常态，所以用 StateStore 记读到哪、用 SnapshotStore 做去重，中断后接着采，避免丢和重。

已经接上的范围：Claude Code 覆盖提问、工具前后、任务完成、上下文压缩、子 Agent 生命周期和通知；Codex 覆盖会话启动、提问、工具前后和完成；Cursor 覆盖会话生命周期、工具、提问和子 Agent 等 12 类事件；Qoder 与 Qoder Work 同时走 hook、IDE 历史、数据库和 Session 文件。

第三，采回来还不能各说各话。原始事件被收成统一的 AgentActivityEntry，依据是 LoongSuite 的 GenAI 可观测语义。这套语义建立在 OpenTelemetry 的 GenAI 语义约定上，并补上社区标准还没覆盖的 Coding Agent 场景。下游只用同一套字段名，例如 gen_ai.usage.input_tokens、gen_ai.session.id、gen_ai.tool.call.id。层级保留为 session、turn、step，再到一次回复或一次工具调用，用来把一轮 ReAct 里的思考、调工具和再推理接回去。新 Agent 接入后，看板、告警和查询不用重做。

第四，不是每个团队都要全文。可以按 Agent 关掉消息正文、工具参数和模型输入输出，只上报模型名、Token、耗时和工具名。对话里又经常夹着云账号密钥、API Key、数据库连接串和私钥，包括开发者贴进来的配置，或 Agent 读到环境文件后写进工具参数的内容。Pilot 在数据进入任何输出通道之前做规则替换：云 AccessKey、API Key、带密码的数据库连接串、PEM 或 OpenSSH 私钥，分别换成固定占位标记。开关是 mask.mode，取值 none、all 或 custom。默认是关闭。打开之后对 SLS、本地 JSONL、HTTP 和 OTLP 同时生效。

第五，不绑死一个后端。安全合规要结构化日志，SRE 要 Trace，本机调试只想看 JSONL。多目标并行写出，一个目标失败不挡住其他通道。本地 JSONL 不依赖外部服务；SLS 用于生产查询；HTTP 接到自建后端；OTLP 接到 Jaeger 或 Grafana Tempo。数据留在用户自己的基础设施，不依赖某个 Agent 厂商。

装上之后，先证明数据在流

安装脚本会把程序放到用户目录下的 .loongsuite-pilot，装上 hook 并拉起后台进程。命令行要填日志服务的 endpoint、project、logstore 和访问密钥。本文不重复那条带密钥占位符的命令。日志和 Trace 可以一起开。Trace 侧打开 collect-trace 之后，每个 session 被还原成一棵调用树：从用户问题到模型推理、工具调用和最终回复。

装完不用改变用法。本地看状态的命令是 loongsuite-pilot monitor start，页面在 127.0.0.1 的 8765 端口。这里看的是采集是否成功：每个 Agent 的事件数、最近活跃时间、上报成功率，以及 Pilot 自己的 CPU 和内存，不是业务质量分。原始事件写在该目录 logs/output 下的 JSONL。文中举的一对事件是 Claude Code 调用 Bash 执行列目录：tool.call 和 tool.result 用同一个工具调用 ID 配成一对，再用 trace、span 和 parent span 接进同一棵树。会话、轮次和步骤是三层 ID，文中的例子写到第 1 轮第 3 步。

进了 SLS 之后，查询直接用归一化字段，不区分数据来自 Claude Code、Cursor 还是 Codex。文章给了三类问法，不是线上大盘的成绩：近 7 天按人和 Agent 汇总某次 llm.response 的输入、输出和总 Token；按 Agent 和工具名统计 tool.result 的次数与平均耗时，取前 10；单次请求总 Token 超过 50000 的会话，取前 20。这些查询可以再收成刷新的看板。文章接着说，看板本身不是目的。

四个问题里，只有一张图给出了单次运行的量

团队真正要回答的被收成四问。哪一问现有字段答不上，就反过来加字段或再适配一个 Agent。

第一问是投入值不值。文章用每人每月 20 到 200 美元的订阅，加上百万级 Token 的调用费，说明一个 50 人团队一年很容易超过一百万元。这是花费量级的举例，不是他们测出来的投资回报率。代码行数、PR 个数、提交频率被写成在 AI 时代失效：写 500 行可能只是循环试错；一次会话可能交出 5 个 PR，也可能 5 次会话才有 1 个有效 PR；机器提交不能当成人工打磨过的提交。缺的是把「AI 做了什么」和「结果是什么」连起来的数据底。Trace 树把入口、Agent 决策、推理步骤、模型调用和工具执行分开。

文中给了一个具体会话，不是汇总指标：用户要求重构认证模块，Claude Code 走了 12 轮。前 4 轮主要是 Read 和 Grep，第 5 到 10 轮主要是 Write 和 Edit，第 11 到 12 轮跑测试。第 7 轮写下的代码在第 8 轮被它自己改掉，这段自修正大约用掉 15% 的 Token，最后得到正确实现。可以往上叠的四个定义是：任务完成率，看会话最后一个事件的类型；Token 效率比，完成一个有效任务平均用多少 Token，并按任务复杂度分开看；人机协作比，会话里 Agent 独立做完的步骤和需要人工介入的步骤各占多少；自修复率，执行中回滚重做的比例。适中的自修复说明模型会反思，过高说明任务已经超出能力边界。这四个数，文章没有给出实测值。

第二问是多种 Agent 并存时怎么选。文章认为「统一用哪一个」问错了，该问的是什么场景用哪一个。没有统一数据时，团队只能靠手感站队。Pilot 的统一字段让同一任务可以放到同一套测量框架里。实验是：把「给一个模块补单元测试」分别交给 Claude Code、Cursor 和 Qoder，三者都完成了任务。页面配图是这一次运行的分析面板，不是重复多次后的均值，也没有方差和通过率。

图上的单次结果和正文判断一致。Claude Code 总耗时 146.899 秒，总 Token 757.64K，其中输入 752.29K、输出 5.35K，模型调用 11 次，工具调用 12 次；模型耗时约占 59.57%，工具约占 40.43%，工具以 Bash 为主，风格是先定位再一次写完测试。Cursor 总耗时 320.159 秒，是三者里最长的；总 Token 732.62K，但输出 Token 11.28K 高于另外两个，对应正文说的输出更多、测试代码更细；模型只调了 7 次，单轮推理最长，工具 23 次，覆盖 Shell、Read、Grep 和 Write。Qoder 总 Token 225.34K，明显低于另两个，总耗时 168.821 秒；模型调了 15 次，是轮次最多的一个，工具 19 次，但工具耗时只约占 0.01%，时间几乎全在模型推理上。正文的结论不是排名，而是各团队用自己的代码库再找组合，而不是把这一次补单测当成普遍胜负。

第三问是多花 Token 是否更好。文章把实践中的现象写成：Token 消耗和输出质量明显非线性，多数情况下 Token 最高的那些会话质量最差。这里没有样本量，也没有相关系数，不能当成已经公布的统计检验。他们追到的三类「Token 黑洞」是：循环试错，轨迹上是一串连续步骤，每步都是写入再跑测试，测试结果持续报错；上下文膨胀，每一轮把上一轮的完整输出都带上，输入 Token 呈台阶上升，复杂任务里有时必要，更多时候是没有裁剪；过度谨慎，模型侧 Token 占到 80% 以上，工具侧很少。用来画这张成本图的字段包括输入、输出、总 Token，以及缓存读入的 Token。文章把这些模式同时看成能力边界信号：哪类任务容易打转、哪类仓库该先管上下文、哪类场景该改回人工。

第四问是谁来审计这些操作。Agent 可以在几分钟里改数十个文件、执行数十条 shell、碰到数百条代码路径，而发起者不是人。提示词注入在文中被列为安全威胁的一类：恶意指令可能出现在代码注释、议题描述或文件内容里，随后的工具调用和正常操作在日志里很难分开。这里只保留威胁类型和审计分层，不写如何构造这类指令。六层分别是：把已接入的 Claude Code、Cursor、Codex、Qoder 放进同一张运行时审计视图；用高风险事件数、当日操作数、敏感写入数和安全事件总数看态势，并按高、中、低排序；从应用、用户、主机、工具类型、外部域名或 IP、命令六个方向列风险主体，标签例子包括危险命令、敏感访问和模型上下文里的密钥泄漏；把外泄拆成攻击驱动的外传、经模型上下文泄漏、以及密钥凭证等敏感类型分布；再下钻到应用、主机、用户、会话、工具、外部域名、目标 IP、密钥、文件路径和命令的关联；最后回到某一个 session，按事件回放参数、工具和上下文，用来判断是正常操作还是被带偏的行为。

开源了，效率看板还在计划里

Pilot 作为 LoongSuite 在端侧的延伸开源，仓库是 github.com/alibaba/loongsuite-pilot。同页还列了 LoongCollector、Python、Go、Java 的 Agent，以及语义约定仓库。文章自己列出的下一步是：再适配 OpenClaw、Hermes、Gemini CLI 和 Cline；做一个开箱即用的效率和成本看板；给第三方适配一份模板。因此，本地 8765 页面确认的是采集是否在流，文中的 SQL 是问法示例。效率和成本的现成看板，在这篇发布时还没有作为默认交付物写完。

限制：20 到 200 美元、50 人超过一百万元、12 轮和大约 15% Token、以及「Token 越高质量越差」，都是举例或尚未给样本的实践判断。Claude Code、Cursor、Qoder 的秒数和 Token 来自同一次补单测的配图，不能外推成基准榜。脱敏默认关闭。对比实验没有重复次数。

出处：阿里云，Alibaba Cloud Native Community，When AI Coding Agent Becomes Infrastructure: Why We Open-Sourced LoongSuite Pilot，2026-07-23，https://www.alibabacloud.com/blog/when-ai-coding-agent-becomes-infrastructure-why-we-open-sourced-loongsuite-pilot_603387