---
{
  "series": "Harness工程研究：让AI Agent好用的工程实践",
  "article_index": 5,
  "topic": "人机协作是光谱：为什么'on the loop'比'in the loop'更聪明",
  "created": "2026-04-25",
  "deai_score": 92.0,
  "pipeline": "series"
}
---

模型生成代码的速度已经远超人类手动审查的生理极限。如果依然将 AI Coding 工具当作某种高性能的自动补全，要求人类逐行审查，这种习惯在处理大规模业务逻辑时将导致工程效率的断崖式下跌。工程师正陷入一种持续的弹窗确认与代码校准的陷阱。

本系列前四篇依次讨论了 Harness 的基本价值、Context 治理、约束机制和验证体系。这些都是系统层面的基础设施。但有一个角色贯穿其中，尚未被单独讨论：人。

### 审批疲劳：人在环路内的安全幻觉

大多数团队在引入 Agent 初期倾向于 Humans In the Loop 模式，试图维持一种逐行检查的掌控感。这种模式在处理孤立、低耦合的代码片段时尚能维持基本秩序，但随着工程规模增长，人类的认知带宽会在高频的操作请求中迅速枯竭。

人类视觉扫描与逻辑理解存在硬性的生理极限。一份包含几百行改动的 Pull Request，人类开发者通常需要十几分钟到半小时进行深度审查，而现代 Agent 可以在几秒内生成同样体量的代码。强制要求人类对每一行生成结果负责会导致严重的认知过载。当系统频繁要求确认时，大脑会产生审批疲劳，习惯性点击确认的概率随之激增。

这种状态提供的安全性是一种心理安慰。资深架构师被困在琐碎的语法校验中，逻辑上的架构风险反而被完全忽略。很多团队发现，在高频确认的一天结束后，提交的代码库中混入了明显的循环依赖或冗余接口，这些错误在手动编写时代反而更容易被察觉。

人在环路（In the Loop）在高通量生成的场景下已经变成了质量瓶颈。人类的注意力是一种昂贵的、易耗散的资源，将其浪费在实时监控模型的每一行输出上是低效的。

### 从修复代码转向构建 Harness

真正能支撑起规模化生成的模式是 Humans On the Loop：工程师的交付物应当从修复好的代码转向更具确定性的 Harness。

正如本系列第三篇《约束让Agent更好用》中讨论的，维护详尽的项目规范、定义严苛的 Linter 规则以及构建自动化的 CI 质量门禁，这些工作的杠杆率远高于在对话框里盲目点击确认。

我观察到，很多团队在面对模型生成的错误逻辑时，第一反应是反复调整 Prompt。这种做法是在进行概率博弈。由于大语言模型的非确定性特征，即使你这次纠正了某个特定错误，同样的错误依然可能在上下文窗口刷新后以新的形式出现。

更有效的策略是构建一套硬性的物理约束。我不再关心模型产生的每一行代码是否完美，我只关心它是否能通过既定的测试阵列。优化 Harness 的回报率始终高于对抗模型的不确定性。

开发者需要从"代码生产者"转型为"环境架构师"，设计一套选择压力系统，让正确的代码在运行中沉淀，让错误的代码在进入仓库前就触发警报。

这里的 Harness 包含三个层面：
首先是静态语义约束。TypeScript 的强类型定义、预定义的架构分层规则以及针对业务领域的 Linter 插件，可以在模型输出的第一时间给出确定性反馈。
其次是动态行为约束。这包括高覆盖率的一体化测试环境。如果 Agent 在一个封闭的、具备实时反馈的测试沙箱中工作，它能通过自我演化修复 80% 的初级逻辑错误。
最后是上下文管理。正如《Context是稀缺资源》中详述的，有效的 Harness 应当包含自动化清空机制，在任务重置时只保留核心设计准则和当前的接口定义。

### 限制即自由

开发者通常担心运行限制会束缚 Agent 的灵活性，但在实际工程中，明确的边界反而赋予了 Agent 更大的自由度。

当你把 Agent 放入沙箱，只要它不触碰红线，它就可以进行成千上万次的尝试而不需要人类干预。明确的约束降低了 Agent 搜索解空间时的盲目性，使其在安全区内表现出更高的自主水平。

将概率性的模型输出包裹在确定性的硬逻辑框架中，是目前最为稳健的实践。确定性是软件工程中最高级的生产力。如果你能确定 AI 生成的代码无法访问敏感密钥，你就可以放手让它重构网络层逻辑。

Agent 无法理解潜规则，只能理解显性的反馈。一个团队必须提供标准化的 API 定义和自动化的测试脚本等显性资产。工程师的任务变成了设计模具和校准感应器。模具限制了流动的方向，但也正是这种限制确保了产出的标准化。

### 协作光谱的动态移位

在人机协作的价值光谱上，人类所占据的点位需要进行动态校准。人类的价值在于输入那些无法被代码自动感知的不对称信息，并将其固化进 Harness 中。

从 In the loop 转向 On the loop，要求开发者从救火队员转变为规则制定者。程序员需要深刻理解系统的边界，将核心业务逻辑转化为 AI 可读的约束。

随着 Agent 开始尝试基于测试反馈自行迭代其 Harness 的配置，一个令人不安的问题浮现了：当 Agent 发现测试覆盖率不足并主动提议增加单元测试时，人类在系统中的核心权威是否会发生漂移？如果 Harness 本身也开始由 AI 生成和优化，人类的角色将进一步退缩到需求定义和最终验收的两端。

目前，建立一套横跨不同场景的"最小可行 Harness"标准依然存在挑战。在低风险任务的自由度与高风险操作的动态收缩之间，大多数框架依然缺乏灵活的调节机制。

我认为，无论 AI 变得多聪明，定义目标和评估不可承受风险的最外层框架始终需要由人类落款。我们通过定义边界来行使权力。这一过程是在通过消除琐碎的认知负担，将程序员提升到更接近系统设计的层面。你不再是代码的搬运工，而是规则的制定者。

如果你还为 AI 写错一个循环而沮丧，说明你的 Harness 出现了漏洞。修复这个漏洞，而不是修复那个循环。

当人类退回到规则制定者的位置，整个系统已经具备了单体架构下的最强形态。然而，面对更加庞大的业务需求，一种直觉式的诱惑开始浮现：既然一个 Agent 这么强，为什么不雇佣十个 Agent 让它们协作呢？下一篇《多Agent不是银弹》将为你戳破这个昂贵的泡沫。