只看结果，已经不够用了

Agent 产品早期最容易演示的，是最后的结果：它写完一段代码，生成一份报告，修掉一个 bug，跑完一个表格任务。结果看起来对，大家就说它可用；结果错了，就让模型再试一次。

这个阶段很快会过去。

一旦 agent 进入生产环境，团队想知道的重点是另一组问题：它为什么选了这个工具，为什么跳过那个文件，为什么在第三步开始跑偏，为什么花了两倍 token，为什么没有触发安全规则，为什么同样的任务昨天能做今天不能做。

这些问题都不是靠最后一段输出能回答的。它们需要运行过程本身可见。

所以我更愿意把最近几条信号放在一起看：HN 上有人做 MCP-native 的 eval、observability 和 debugging 工具；GitHub 上的 codegraph 把代码库预先建成知识图谱，目标是减少 token 和工具调用；论文侧从 Apple 到 AgentTrust、EvalAgent，都在把评估从「看最终答案」推向「理解模型和 agent 的执行条件」。它们说的不是同一件产品，但指向同一个缺口：Agent 需要一层运行时可观测性。

这层不会只是日志面板。它会变成 Agent 平台的基础设施。

Agent 的错误通常发生在中间

传统软件出错，至少还有调用栈、异常、日志、监控指标。一个接口慢了，可以看延迟；一个数据库连接失败，可以看错误码；一次发布回滚，可以看 diff 和告警。

Agent 出错更麻烦。它可能第一步就误解目标，第二步读错文件，第三步选错工具，第四步把错误结果当成依据，最后给出一段看起来很完整的回答。最终答案只是事故现场，事故链条在前面。

如果没有轨迹记录，排查只能靠猜。

开发者会问：它到底读了哪些文件？用了哪些上下文？工具返回了什么？中间有没有自我检查？有没有忽略系统规则？有没有在某一步凭空补全？这些都需要被记录下来，而且记录不能只是一大段模型输出。它要能按任务、步骤、工具、成本、权限、输入输出拆开看。

这就是为什么 agent observability 会比传统 LLM 应用监控更重。聊天机器人主要看响应、延迟、命中率和用户反馈；agent 还要看行动序列。它不只是生成文本，而是在一个工具环境里做决定。

如果决定不可见，生产化就会停在演示层。

MCP 让工具变多，也让排查变难

MCP 的价值，是把模型和外部工具之间的连接方式标准化。它让 agent 更容易接数据库、文件系统、浏览器、设计工具、业务系统和内部服务。

但工具越多，可观测性越重要。

一个 agent 只有三个工具时，出错路径还比较容易猜。一个 agent 面对几十个 MCP server、上百个 tools、不同权限和不同返回结构时，失败就会变成组合问题。它可能选错 server，也可能选对 server 但传错参数；可能工具返回了异常，也可能返回了「看似正常但语义错误」的数据；可能某个工具太慢，导致 agent 改走一条更差的路径。

HN 上出现 MCP-native 的 eval、observability、debugging 工具，不意外。MCP 把工具生态打开之后，下一步自然就是测试这些工具、记录这些调用、复盘这些轨迹。否则团队只会得到一堆「agent 有时很好，有时很怪」的体验反馈。

有用的可观测性应该回答三件事。

  • 这次任务的工具调用链是什么。
  • 每一步输入、输出、耗时和成本是什么。
  • 哪一步最可能导致最终失败。

这三件事看似朴素，但决定了 agent 是否能被工程团队接手。如果一次失败无法复现、无法归因、无法比较两个版本的差异，就很难进入稳定迭代。

代码图谱说明成本问题也在进入运行时

codegraph 这类项目的切入点看起来不同。它是在把代码库预先索引成知识图谱，让 agent 查询结构化的代码知识，减少 token、减少工具调用、提高定位速度。

这也是可观测性的一部分。

过去我们谈 agent 成本，常常只看总 token 或单次调用价格。生产环境里更关键的是「无效成本」：agent 反复读同一个目录，搜索过宽的关键词，打开无关文件，跑不必要的测试，或者在没有足够上下文时来回试错。

这些浪费不一定会让最终答案立刻变差，但会让系统不可控。一次任务多花几毛钱没什么，成千上万次任务都在无效搜索，就会变成真实成本。更糟的是，无效搜索通常也带来更多错误机会。

代码图谱、上下文索引、检索缓存和工具调用摘要，都是在解决同一个问题：让 agent 在行动之前知道环境结构，在行动之后留下可分析的路径。它们把「上下文管理」从提示词技巧变成运行时工程。

以后评价一个 coding agent，不应该只看它能不能改对一个 bug。还要看它为了改这个 bug 读了多少无关文件，调用了多少工具，是否重复搜索，是否能解释自己为什么打开这些文件。

这不是洁癖。生产系统必须知道钱花在哪里，时间耗在哪里，错误发生在哪里。

论文侧正在补评估语言

Apple 的《The Illusion of Thinking》被讨论很多，容易被简化成一句「推理模型没那么会推理」。更有价值的地方在于，它提醒我们：只看模型输出，很容易误判模型内部能力。任务复杂度、提示方式、搜索空间和评估设计都会影响结论。

Agent 评估也有同样的问题，而且更严重。

一个 agent 在 benchmark 上完成任务，可能是因为工具刚好合适，环境刚好简单，检查刚好宽松。换成真实项目，工具更多、权限更复杂、状态更多、失败成本更高，表现可能完全不同。

AgentTrust 这类多模态 agent 可信度 benchmark，把安全、隐私、可靠性、鲁棒性放进评估框架；EvalAgent 则尝试让 agent 参与生成式模型评估。这些工作说明研究侧也在寻找新的评估语言：问它在什么条件下可靠，在哪些任务里容易失效，评估过程本身能不能被自动化和复用。

工程侧需要的也是这种语言。

一个生产 agent 的评估应该覆盖任务完成率，但不能止步于此。它还要看工具误用率、权限越界风险、上下文浪费、重复调用、失败恢复、异常解释、人工接管点。否则指标会很好看，系统却很难交给用户。

可观测性会把 eval 变成持续系统

很多团队现在做 eval，还是项目上线前跑一批测试集。这个方式对普通 LLM 应用有用，但对 agent 不够。

Agent 的行为和环境强绑定。工具变了，权限变了，代码库变了，网页结构变了，业务流程变了，它的表现都会变。一次性 eval 只能证明某个时间点、某个环境、某组样例下看起来可用。

更合理的方式，是把 eval 接进运行时。

每次 agent 执行任务，都记录轨迹；每次失败，都能回放；每次人工纠正，都能变成新样例；每次工具或模型升级，都能拿历史轨迹做对比。这样 eval 就重点是持续系统的一部分。

这会改变产品设计。

未来的 Agent 平台可能会默认带五类能力：trace、replay、cost、policy、eval。Trace 记录行动轨迹；replay 复现关键步骤；cost 拆解 token 和工具费用；policy 判断权限和规则；eval 把历史任务和新版本做对比。

这五件事连在一起，才像一个能进生产的系统。

只提供「模型调用 + 工具接口」的平台，会越来越像半成品。工作流平台必须能解释一次任务，而不只是执行一次任务。

企业不会为不可解释的自动化买单

很多 agent 讨论喜欢用「替代人」做结尾，但企业采购和内部平台建设更关心另一件事：出了问题谁负责，怎么回滚，怎么审计。

如果 agent 改坏代码，团队要知道它改动前看了什么、为什么判断这个改法可行、测试有没有跑、失败信号有没有被忽略。如果 agent 做财务分析，团队要知道数据来自哪里、公式怎么来的、假设是否被改过。如果 agent 帮客服或运营执行动作，团队要知道权限链路和人工确认点。

不可解释的自动化，规模越大，风险越大。

可观测性重点是为了让组织敢用。它给工程团队排查问题，给安全团队做审计，给管理者看成本，给业务团队解释失败。没有这层，agent 就只能停留在个人效率工具和演示项目里。

这也是为什么我认为 observability 会成为 Agent 平台竞争的一部分。模型公司、开发工具、MCP 生态、企业平台都会往这层补。谁能把工具调用、上下文、成本、策略和评估统一起来，谁就更接近企业需要的控制面。

下一阶段是更多仪表

Agent 生态已经不缺演示。缺的是把演示变成系统的方法。

系统不只要能完成任务，还要能被监控、被复盘、被评估、被审计、被优化。过去这套能力属于软件工程的基本功。Agent 进入生产以后，也逃不开这套基本功。

所以接下来值得关注的，不只是哪个 agent 又能自动做一个漂亮 demo，而是它有没有留下可解释的轨迹，有没有可复现的失败样本，有没有成本拆解，有没有工具调用审计，有没有跨版本对比。

这些东西不如模型发布会热闹，但会决定 agent 能不能从个人助手走进团队系统。

最终，Agent 可观测性会成为一层基础设施。它连接模型、工具、权限、成本和 eval，也连接产品演示和生产信任。没有这层，agent 做得越多，组织越不敢放手；有了这层，失败才会从神秘现象变成可以处理的工程问题。