作者: Phodal Huang 2026年4月22日 15:54

在 Thoughtworks（现 Inspire） 的最后一个月里，我一直在为“下一个项目”准备一套 AI Coding 的端到端方案。这个方案基于 Claude Code、Web UI、Proxy、Agent Trace 和 Skills 等能力构建，但由于种种原因，最终未能在客户项目中落地。

其中一个核心设计，是基于 ACP 协议的 Agent Trace。它可以记录每个 Agent 在执行过程中的关键行为，例如调用了哪些工具、读取了哪些文件、访问了哪些上下文等。基于这些 Trace，Agent 能够获得足够的过程信息，从而进一步分析用户与 AI 协作的方式，识别个性化提示词的优化空间，并帮助每个人持续提升提示词质量与 AI 使用效果。

虽然这套方案当时没有真正进入客户项目，但它并没有停留在概念层面。后来在 Routa 项目中，除了原功能本身，我重新找到了几个更合适的落点：将其用在提升多 Agent 系统的协作上。

引子：从 Agent Trace 到记录协作历史

Cursor 提出的 Agent Trace 给了一个很好的参照：它把 AI 生成代码背后的贡献、对话和文件范围记录成一种标准化数据。它强调的是一种开放、可互操作、 供应商中立的格式，用来记录 AI 贡献与人类作者之间的关系。它本身并不负责判断 AI 贡献质量，也不试图替代 UI 或质量评估系统。

对我来说，Agent Trace 真正有意思的地方是：Agent 的执行过程可以被结构化记录下来，并成为一种新的工程数据资产。

在 Routa 的实现里，我们做的是另一条类似的路径：基于 ACP，把 Agent 的执行过程转换成类似 Agent Trace 的 session JSONL 格式。 它记录的不只是最终改了哪些代码，而是 Agent 如何完成任务：工具调用、文件读取、上下文访问、提示词片段、任务切换、失败信号和用户接管。

这类数据一旦被记录下来，就不只是日志。它可以被聚合，可以被分析，可以被归因到功能和文件，也可以在下一次任务开始前重新被系统使用。换句话说：

Agent Trace 的价值，不只是记录 AI 做了什么，而是让协作历史第一次成为可以被分析和复用的数据。

第一个试验：从 Trace Learning 到 Feature Explorer，构建需求和 Session 的关联

在有了 Trace Learning 的初步想法，我的第一想法是：先通过可视化看清楚这些历史和需求、功能、文件之间的关系，帮助我们更好地分析。毕竟单条 Trace 的价值有限，真正有价值的是多条 session 之间反复出现的关系：某个功能经常访问哪些文件，某类任务总是调用哪些工具，哪些文件是 Agent 反复读取的热点， 哪些路径经常出现在失败之前。

因此，我们之前的尝试是把 Trace 和功能结合起来，也就是Feature Explorer，即上一篇文章介绍的《从写清 Spec 到看懂功能：在 Session 历史中使用 Routa 重建需求全景》。Feature Explorer 关注的不是“这个 session 做了什么”，而是这些 session 能否重新归因到 feature、需求、文件和代码路径上。只有当 Trace 被归因到 Feature，它才会从时间顺序上的历史记录，变成有工程含义的信号。

这也是 Trace Learning 的雏形：不是把历史 session 直接塞给模型，也不是训练一个“更懂项目”的模型，而是在模型外部提炼可观察、可审查、可回滚的经验。

session trace
  → file / tool / context signals
  → feature attribution
  → repeated patterns
  → reusable context

但这还只是分析。真正的问题是：当新的任务进入 Kanban 时，这些历史能不能帮助 Agent 更好地启动？

Kanban Harness 的质量问题：历史上下文能改进 Agent 的启动质量吗？

把这个问题真正推到前台的，是 Kanban。

在 Routa 中 —— 一个看板驱动的多 Agent 协作里，我们经常可以看到一个比 “能不能继续记录 Trace” 更现实的问题：同一张卡片每换一个 specialist，都在重复补课。

Dev 要重新找入口文件，Review 要重新理解改动边界，plan 角色要重新猜功能范围。即使系统已经留下了会话、trace、文件变更和若干 制品，下一位 Agent 依然很可能从一个相当原始的状态开始。这种冷启动带来的浪费，远比 “少一次事后复盘” 更伤系统效率。 因此 Kanban Harness 的质量问题，是如何将执行后的验证质量，前置到任务启动前的上下文质量。

在 Routa 中通过构建 Task-Adaptive 来实现一次启动前的预整理。它会先看这张卡片现在处在哪个阶段：是在规划、实现，还是 review。然后再从看板状态、 历史会话、即时分析结果和已有摘要里，挑出对当前角色真正有用的线索，以少让下一位 Agent 做无效定位。

同样是历史上下文，不同角色需要看的东西其实不一样。plan 更需要知道功能意图、拆解方向和相关功能；Dev 更关心入口文件、相关模块、接口和之前有没有人踩过坑；review 则需要尽快看清改动边界、风险点和验证路径。

如果把这几种历史形态并排看，差异会更清楚。

所以 Kanban 逼出来的不是一个更大的全局 Memory，而是一套更实用的接手机制。

它要解决的问题很朴素：前一个 Agent 留下了那么多东西，后一个 Agent 不应该再从零开始翻。系统应该先帮它把“这张卡片现在最该看什么”整理出来。

任务自适应 Harness

Task-Adaptive Harness 是一种围绕当前任务临时组装执行边界的机制。它不预设固定环境，而是在任务开始前，根据目标、证据、历史和约束，收缩出这一次真正需要的上下文、工具和规则。

其核心可以归纳为三条原则：

• 上下文应由任务决定，不应由历史堆积决定。 系统不应默认继承全部历史，再让模型自己筛选重点，而是先从任务出发，明确需要哪些功能、文件和会话，再反向收缩上下文范围。关键不在于“记住多少”，而在于“带上的是不是这次任务真正需要的”。

• 判断应建立在证据上，不应建立在摘要上。 与其先生成一段看起来合理的总结，不如优先恢复可验证的证据：命中的文件、相关会话、失败记录和匹配理由。总结只是证据的整理结果，而不是入口；证据不足时，系统应明确降级，而不是假装理解。

• 约束应在执行前生效，不应在执行后解释。 历史和规则的价值，不是在事后用于复盘，而是在任务启动时就介入执行环境，直接影响工具选择、权限范围和行为边界。约束越早生效，系统越可控，后续偏差也越少。

Routa 的实现：从历史 Session 到多 Agent 的协作记忆

把 Routa 的这部分实现展开来看，它理你是看成一种分层的协作记忆。

1. 在会话开始之前，系统会先把任务目标、当前角色和相关历史收成一个可以启动的入口。这样 Agent 进入任务时，不再只是模糊地“继续做下去”，而是从一个已经带着方向感的起点开始。
2. 等到真正启动时，这些历史会被进一步装配成执行边界：哪些功能线索更相关，哪些文件值得先看，哪些失败应该绕开，哪些工具路径更合适。到了这里，Harness 也不再只是静态配置，而更像任务启动前的一次现场布置。
3. 一次委派结束之后，系统留下来的也不只是可供回放的 trace，而是一份可以交接的状态：前面试过什么，哪些路已经走不通，哪些地方还不确定。这样下一位 Agent 接手时，面对的就不再是一整段漫长 transcript，而是一份真正能接着往下做的上下文。
4. 再往后，随着运行次数变多，这些状态还会继续沉淀。反复出现的成功路径、常见失败、稳定的工具顺序和验证方式，会慢慢长成某类任务的经验。到这一步，历史影响的已经不只是如何回顾过去，也包括下一次如何更好地开始。

回头看，这几层记忆其实都在回答几件很朴素的事：任务怎么开始，边界怎么形成，工作怎么交接，经验又怎么留下来。

小结：从本地 Harness 到全流程 Harness

写到这里，我会觉得，前面绕了这么一圈，最后留下来的其实是一个很简单的问题：一次任务结束之后，系统到底有没有真的留下什么。

有时候看上去是留下了很多东西。trace 也在，session 也在，文件改动也在，连失败记录都可以回放。可下一位 Agent 接手时，还是要重新找入口，重新判断边界，重新摸一遍现场。这样看，它们更像是被保存下来的过去，而不是能够继续往前走的历史。

从 Trace，到 Feature Explorer，再到 Task-Adaptive Harness，这条线表面上看是在补系统能力，实际上更像是在回答一个协作里的老问题：

前面的人做过的事，怎么才能真的被后面的人接住。

如果这件事能成立，那么 Harness 讨论的也就不只是本地那套提示词、脚本和规则了。它会慢慢变成一种更长的东西，穿过一次次任务启动、交接和继续执行， 把方向、边界和经验留下来。

所谓多 Agent 协作，也许并不只是把更多 Agent 放进同一个流程里。更重要的是，系统开始学会不让每一次开始，都真的从头开始。