真实工业样本里的三条共同经验 把 Coding Agent 推到生产环境、连续使用六个月以上的工程团队,几乎都会沉淀出一组类似的经验。这些经验不是产品宣传话术,是工程团队在面对真实代码、真实 CI、真实运维问题时的反复试错、反复修正、反复沉淀的结果。把这些经验合并起来看,可以提取一组关于 Harness 工具链选择的真实工业样本。 第一组经验是"代理性必须可追溯"。当一个 Agent 在 50 个

真实工业样本里的三条共同经验

把 Coding Agent 推到生产环境、连续使用六个月以上的工程团队,几乎都会沉淀出一组类似的经验。这些经验不是产品宣传话术,是工程团队在面对真实代码、真实 CI、真实运维问题时的反复试错、反复修正、反复沉淀的结果。把这些经验合并起来看,可以提取一组关于 Harness 工具链选择的真实工业样本。

第一组经验是"代理性必须可追溯"。当一个 Agent 在 50 个文件的 commit 里做了一个关键决定,几周后这条决定被发现是错的——这时候追责链路是断裂的:不知道哪个 Agent 做的、不知道在哪一轮会话、不知道基于什么上下文。事后追责的成本远高于事前预防的成本。第二组经验是"质量门必须确定"。LLM 提议改什么是一回事,提议是否合理是另一回事。质量门必须基于预设规则——文件大小限制、测试覆盖率、代码风格——而不是 LLM 自己审核 LLM。第三组经验是"Harness 工具链必须和 Agent 协同设计"。如果 CI、Harness、Agent 是分别独立设计的,Agent 在生产里会反复撞墙。这三组经验来自两个相互独立的工程实践,角度不同但结论高度一致。

多 Agent 治理的工业样本

2026 年 2 月公开的一个独立工程实践,记录了"六个月只让 AI Agent 写代码"的完整链路。这位工程师在六个多月里同时协调 Claude Code、Codex CLI、Gemini CLI 三家不同厂商的 Agent,在多个并行终端里持续推进一个生产项目。这套系统运行到六个月时已经积累了 1100 多条决策记录,每条记录都指向一个具体的 Agent 行为、一个具体的 git commit、一个具体的质量判定。

这位工程师明确记录的几条经验值得系统化讲清楚。第一条是"绝不信任 sub-agent 的可追溯性"。当一个 Agent spawn 出 sub-agent 完成某项任务时,sub-agent 的决策过程对父 Agent 是黑盒;一旦事后出问题,无法定位是哪一层 sub-agent 的哪一步决策出了问题。这位工程师的解法是"不用 sub-agent"——所有任务都由独立 Agent 在独立终端里完成,各自有完整的上下文窗口,决策记录由 orchestrator 统一汇总。这条选择降低了多 Agent 协作的灵活性,但换来完整的可追溯性,在工程上是显见的取舍。

第二条是"质量门必须确定化、不能 LLM 化"。这位工程师明确表示,LLM 提议改什么、提议改到哪里、提议怎么改——这些是 LLM 的事;但"提议是否合理"必须由确定性规则判定,而不是由另一个 LLM 判定。具体落地是"自动 advisory 工具"——按预设规则(文件大小限制、测试覆盖率、未关闭的 blocker)检查 LLM 的每次输出,任何不通过的输出直接拦截,LLM 必须重做。这条机制和现代静态扫描器很像,但关键是它在 Agent 循环内执行,而不是在 PR 阶段执行——Agent 还没把代码提交就被拦下来。

第三条是"上下文轮转必须自动化"。当 Agent 上下文窗口用满时,几乎所有 Harness 都会失败——会话断开、决策断裂、进度丢失。这位工程师用 Claude Code hooks 实现了自动化上下文轮转:检测上下文使用率、写入结构化交接文档、清空窗口、在新窗口里恢复任务。整个过程零人工介入。这条机制在传统开发里不需要,但在长会话 Agent 协作里是必需——上下文窗口终将耗尽,提前处理比事后崩溃强得多。

AI 编码 IDE 选择的工业样本

2025 年 3 月公开的另一份独立工程实践,从不同角度覆盖了同一组工程经验。这份实践的当事人尝试用 AI junior developer 写 GitHub PR,失败后转向做 JetBrains 的 AI 编码助手,沉淀了若干关于 Harness 选择的工程判断。

这份实践里被明确记下来的经验有一条值得专门讲:"Agent 不是为真实代码库设计的,因为它们的 CI 不是为 Agent 设计的。" 这句话指向一个具体的工程现实——多数企业的 CI 流程假设 PR 由人类工程师提交,人工 review 触发,人工 merge 进入主干;Agent 提交 PR 的频率远高于人类,CI 流程里的人工环节(如"等待 reviewer 响应"、"等待 reviewer 主动 review")就成为瓶颈。具体表现是 GitHub Actions 跑得太慢,Agent 等到不耐烦就触发"再去试一次"的循环,浪费 token、浪费算力、浪费开发者注意力。

这份实践给出的解法是"Harness 必须为 Agent 重新设计"——CI 不能假设有人类在等,所有等待环节必须自动化;review 不能依赖"主动 reviewer 找上来",必须改成"被动等事件触发";merge 不能依赖"人工点确认",必须改成"满足规则自动 merge"。这位工程师的转向——从"让 Agent 适配现成 Harness"到"为 Agent 重新设计 Harness"——在工程上指向一个清晰的认知:Harness 的设计假设决定了 Agent 能否在生产里持续运行。

这位工程师还记录了一条关于 Harness 选择的"反共识"观察:"多数 Agent 仍然是 while-loop 包装"。While-loop 包装指"Agent 失败 → 重试 → 失败 → 重试"这种简单循环;在过去一代模型里这种包装足够,因为模型出错率低、任务简单;在新一代模型里,简单循环明显慢,这位工程师的解法是"用代码图谱直接看相邻文件",跳过"在循环里 grep"。这条观察在工程上指向一个具体的设计选择——Harness 的核心策略不是"循环到对为止",而是"在 Agent 开始循环之前,先给它足够的代码上下文"。

把两条样本合并:Harness 工具链的工程新基线

把两个独立样本的经验合并,可以画出 Harness 工具链在 Coding Agent 时代的工程新基线。这条基线由五条构成,缺一不可。

第一条,Harness 必须能完整追溯 Agent 的每次决策。决策记录必须包含 Agent ID、时间戳、任务上下文、决策结果、影响的文件。任何一次工具调用、任何一次文件修改、任何一次代码评审,都必须落到结构化的、不可篡改的存储里,事后可以被检索、被回放、被审计。这条基线解决"事后追责"问题——可追溯是治理的最低要求。

第二条,Harness 必须有确定性质量门,不能依赖 LLM 自审。LLM 提议改什么是它的自由,但提议是否合理必须有确定性的规则判定——文件大小限制、测试覆盖率、代码风格、依赖审计。质量门按预设规则自动执行,任何不通过的输出立即退回 Agent,不允许 LLM 跳到下一步。这条基线解决"Agent 错改无人知"的问题。

第三条,Harness 必须支持自动化上下文轮转。Agent 上下文窗口终将耗尽,Harness 必须能自动检测、自动交接、自动恢复。这条机制不是可选优化,是 Agent 长会话运行的必需基础设施。这条基线解决"会话断开、决策丢失"的问题。

第四条,Harness 必须为 Agent 重新设计 CI 流程,而不是套用人类工程师的 CI。Agent 提交 PR 的频率远高于人类,所有依赖"等待人类 reviewer 响应"的环节都必须自动化;review 必须按事件触发,merge 必须按规则自动。这条基线解决"Agent 在 CI 里空转浪费"的问题。

第五条,Harness 必须支持多种厂商 Agent 并行协作,而不仅绑定一家。当 Harness 只支持一家 Agent 时,工程团队就被锁死在单家厂商的能力边界上;当 Harness 支持多家 Agent 并行时,工程团队可以根据任务画像选择最合适的 Agent,或者让不同 Agent 协作完成复杂任务。这条基线解决"厂商锁定"问题——多个独立样本都用了多家 Agent 并行,正是这条基线的工程现实。

从 Coding Agent Harness 推到所有企业 Agent Harness

把视野拉宽到企业 Agent Harness 全景,以上五条基线具有普遍意义。任何企业内部被授予"长会话、自主决策、工具调用"能力的 Agent——不只是 Coding Agent,还包括销售 Agent、客服 Agent、运维 Agent、数据分析 Agent——都会面对同一组 Harness 问题:决策怎么追溯、质量怎么判定、上下文怎么轮转、CI 流程怎么为 Agent 重设计、多 Agent 怎么并行协作。

企业 Agent 治理负责人现在应当把 Coding Agent Harness 的工程新基线作为整个企业 Agent Harness 设计的样板工程。具体来说,"可追溯、确定性质量门、自动化上下文轮转、为 Agent 重设计的 CI、多 Agent 并行"这五条规则应当通用化,覆盖企业内部所有 Agent 的所有 Harness 场景。每一条规则对应一个独立的工程组件——可以是审计日志服务、可以是质量门服务、可以是上下文轮转 hooks、可以是事件驱动的 CI 框架、可以是多 Agent 调度器——实现形式各异但原则一致。

企业 Agent 治理负责人现在必须回答的三个问题

面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 Harness 是否能完整追溯 Agent 的每次决策?如果决策记录缺失、Harness 不可审计、Agent 行为不可回放,事后追责就不可能。

第二个问题:你企业内部质量门是基于确定性规则还是基于 LLM 自审?如果是 LLM 自审,Agent 错改无人知;如果是确定性规则,质量门可以在 PR 之前就拦下大部分问题。

第三个问题:你企业内部 CI 流程是为人类工程师设计的还是为 Agent 设计的?如果是前者,Agent 会在 CI 空转里浪费大量 token;如果是后者,Agent 才能在生产里持续运行。

结语

Coding Agent 的能力边界在过去一年被显著推前,从"按 prompt 写一段代码"演化到"按 prompt 持续维护一个项目六个月以上"。每推前一步,工程侧的 Harness 基线就必须同步推前一步。把"Agent 套用现成 Harness"作为主要思路的部署,在两条独立工业样本里被反复证伪。把"可追溯、确定性质量门、自动化上下文轮转、为 Agent 重设计的 CI、多 Agent 并行"作为基线,重新设计 Harness 工具链,是当下能落地的工程基线。

任何企业 Coding Agent 项目,只要涉及 Agent 持续运行、Harness 协同设计、CI 流程整合,工程基线就必须做到这五条——可追溯、确定性质量门、自动化上下文轮转、为 Agent 重设计的 CI、多 Agent 并行——否则,今天不是某次 Agent 决策丢失的主角,也会是下一次 Harness 协同失败的主角。