任务自适应 Harness：从 Trace 到多 Coding Agent 的协作记忆
任务自适应 Harness：从 Trace 到多 Coding Agent 的协作记忆
作者： Phodal | 发布时间： 2026-04-22 来源： phodal
前言
在 Thoughtworks（现 Inspire）的最后一个月，作者为一个项目准备了一套基于 Claude Code、Web UI、Proxy、Agent Trace 和 Skills 的 AI Coding 端到端方案，但最终未能在客户项目中落地。
其中一个核心设计是基于 ACP 协议的 Agent Trace——记录每个 Agent 执行过程中的关键行为（工具调用、文件读取、上下文访问等），让协作历史第一次成为可分析和复用的数据。
虽然这套方案当时没有真正进入客户项目，后来却在 Routa 项目中找到了更合适的落点：提升多 Agent 系统的协作质量。
代码详见：https://github.com/phodal/routa
从 Agent Trace 到协作历史
Cursor 的参照
Cursor 提出的 Agent Trace 提供了一个很好的参考：把 AI 生成代码背后的贡献、对话和文件范围记录成标准化数据，强调开放、可互操作、供应商中立的格式。
Agent Trace 真正有意思的地方在于：Agent 的执行过程可以被结构化记录下来，成为一种新的工程数据资产。
Routa 的实现
在 Routa 中，基于 ACP，把 Agent 的执行过程转换成类似 Agent Trace 的 session JSONL 格式。它记录的不只是最终改了哪些代码，而是 Agent 如何完成任务：
- 工具调用
- 文件读取
- 上下文访问
- 提示词片段
- 任务切换
- 失败信号
- 用户接管
Agent Trace 的价值，不只是记录 AI 做了什么，而是让协作历史第一次成为可以被分析和复用的数据。
第一个试验：Trace Learning 到 Feature Explorer
单条 Trace 的局限
单条 Trace 的价值有限，真正有价值的是多条 session 之间反复出现的关系：
- 某个功能经常访问哪些文件
- 某类任务总是调用哪些工具
- 哪些文件是 Agent 反复读取的热点
- 哪些路径经常出现在失败之前
Feature Explorer
将 Trace 和功能结合起来，构建需求和 Session 的关联：
session trace
→ file / tool / context signals
→ feature attribution
→ repeated patterns
→ reusable context
核心洞察： 只有当 Trace 被归因到 Feature，它才从时间顺序上的历史记录，变成有工程含义的信号。
这正是 Trace Learning 的雏形——不是把历史 session 直接塞给模型，而是在模型外部提炼可观察、可审查、可回滚的经验。
Kanban Harness 的质量问题
真实痛点
在 Routa（看板驱动的多 Agent 协作系统）中，一个比「能不能继续记录 Trace」更现实的问题是：
同一张卡片每换一个 specialist，都在重复补课。
- Dev 要重新找入口文件
- Review 要重新理解改动边界
- plan 角色要重新猜功能范围
即使系统已经留下了会话、trace、文件变更和若干制品，下一位 Agent 依然很可能从相当原始的状态开始。
这种冷启动浪费，远比「少一次事后复盘」更伤系统效率。
核心问题
如何将执行后的验证质量，前置到任务启动前的上下文质量？
任务自适应 Harness
定义
Task-Adaptive Harness 是一种围绕当前任务临时组装执行边界的机制。它不预设固定环境，而是在任务开始前，根据目标、证据、历史和约束，收缩出这一次真正需要的上下文、工具和规则。
三条核心原则
① 上下文应由任务决定，不应由历史堆积决定
系统不应默认继承全部历史，再让模型自己筛选重点。而是：
- 先从任务出发，明确需要哪些功能、文件和会话
- 再反向收缩上下文范围
关键不在于「记住多少」，而在于**「带上的是不是这次任务真正需要的」**。
② 判断应建立在证据上，不应建立在摘要上
与其先生成一段看起来合理的总结，不如优先恢复可验证的证据：
- 命中的文件
- 相关会话
- 失败记录
- 匹配理由
总结只是证据的整理结果，而不是入口。证据不足时，系统应明确降级，而不是假装理解。
③ 约束应在执行前生效，不应在执行后解释
历史和规则的价值，不是在事后用于复盘，而是在任务启动时就介入执行环境，直接影响工具选择、权限范围和行为边界。
约束越早生效，系统越可控，后续偏差也越少。
三种历史形态对比
| 历史形态 | 什么时候进入上下文 | 好处 | 问题 |
|---|---|---|---|
| 原始 trace / 对话记录 | 运行结束后 | 细节最完整，可以回放 | 下一轮阅读成本高，接手的人要自己筛 |
| 功能复盘 | 做功能分析时 | 能把历史挂到功能和文件上 | 更像事后理解，缺少当前任务角色的约束 |
| 任务自适应 Harness | 会话启动前 | 能提前整理相关会话、文件、模块和任务类型 | 依赖提示和历史命中质量，错命中时要能降置信度 |
第二个试验：多 Agent 的协作记忆
把 Routa 的实现展开来看，是一种分层的协作记忆：
第一层：启动入口
在会话开始之前，系统把任务目标、当前角色和相关历史收成一个可以启动的入口。
Agent 进入任务时，不再只是模糊地「继续做下去」，而是从一个已经带着方向感的起点开始。
第二层：执行边界装配
等到真正启动时，历史被进一步装配成执行边界：
- 哪些功能线索更相关
- 哪些文件值得先看
- 哪些失败应该绕开
- 哪些工具路径更合适
此时 Harness 不再只是静态配置，而更像任务启动前的一次现场布置。
第三层：状态交接
一次委派结束后，系统留下来的不只可供回放的 trace，而是一份可以交接的状态：
- 前面试过什么
- 哪些路已经走不通
- 哪些地方还不确定
下一位 Agent 接手时，面对的就不再是一整段漫长 transcript，而是一份真正能接着往下做的上下文。
第四层：经验沉淀
随着运行次数变多，状态会继续沉淀：
- 反复出现的成功路径
- 常见失败
- 稳定的工具顺序
- 验证方式
到这一步，历史影响的已不只是如何回顾过去，也包括下一次如何更好地开始。
不同角色的不同需求
同样是历史上下文，不同角色需要看的东西其实不一样：
| 角色 | 关注重点 |
|---|---|
| plan | 功能意图、拆解方向、相关功能 |
| Dev | 入口文件、相关模块、接口、之前有没有人踩过坑 |
| review | 改动边界、风险点、验证路径 |
小结：从本地 Harness 到全流程 Harness
核心问题
一次任务结束之后，系统到底有没有真的留下什么？
有时候看上去是留下了很多东西。trace 也在，session 也在，文件改动也在，连失败记录都可以回放。可下一位 Agent 接手时，还是要重新找入口，重新判断边界，重新摸一遍现场。
这样看，它们更像是被保存下来的过去，而不是能够继续往前走的历史。
回答协作里的老问题
从 Trace，到 Feature Explorer，再到 Task-Adaptive Harness，这条线表面上是在补系统能力，实际上更像是在回答一个协作里的老问题：
前面的人做过的事，怎么才能真的被后面的人接住？
如果这件事能成立，那么 Harness 讨论的也就不只是本地那套提示词、脚本和规则了。它会慢慢变成一种更长的东西，穿过一次次任务启动、交接和继续执行，把方向、边界和经验留下来。
最终结论
所谓多 Agent 协作，也许并不只是把更多 Agent 放进同一个流程里。更重要的是，系统开始学会不让每一次开始，都真的从头开始。