Harness Control：AI Agent 最危险的时刻，不是做错事，而是系统已经失去“下一步”的决定权

Agent 的失控，往往不是从大事故开始的。

它往往从一个很小、甚至看起来很合理的瞬间开始。

比如一个代码 Agent 刚跑完测试。结果里已经明确写着失败。正常的系统此时应该停下来，进入“修复”或者“等待人工判断”。但有些 Agent 系统不会。它会继续改文件、继续生成提交说明，甚至继续往发布链路上走。 不是因为它故意胡来，而是因为系统从来没有认真回答过一个问题：测试失败之后，谁有权决定“下一步还能不能继续”？

这就是 Control 这一层要解决的事。

在 Harness 体系里，Environment 决定 Agent 活在什么样的世界里，Tool 决定它能调用什么能力，Memory 决定它记不记得住过去，Evaluation 决定系统知不知道它做得对不对；而 Control 决定的，是系统是否还握着“下一步”的权力。

这个问题很容易先被理解成“流程编排”或“长任务管理”。这当然相关，但还不够。Control 真正管的，不是流程本身，而是四种更底层的权力：

• 放行：这一步现在能不能做
• 暂停：现在是不是必须停下来
• 恢复：出了问题从哪里继续
• 终止：什么时候必须结束，不再继续

如果这四种权力不在系统手里，而是默认滑给模型，Agent 迟早会失控。

一、真正危险的，不是它会犯错，而是它错了还在往前走

一个 Agent 真正让人后背发凉的时刻，通常不是它第一次出错。

真正危险的，是它已经出错了，系统却像什么都没发生一样，继续把后面的门一扇扇打开。

测试明明失败了，它还在生成提交说明。 审批节点明明到了，它还在继续改配置。 某个工具已经连续报错三次，它却只是换个说法再试一遍。 这时候你会突然意识到，问题已经不是“这一步做得对不对”，而是为什么系统还允许它继续往下走。

这也是 Control 必须单独拿出来讲的原因。

模型犯错并不可怕。工具失败也不可怕。真实生产里，这两件事每天都会发生。可一个系统一旦缺少控制层，错误就不再只是一个局部错误，而会开始往后传：

• 一次失败的测试，被当成“还可以继续尝试”
• 一次本该暂停的节点，被当成“先做了再说”
• 一次需要人拍板的动作，被默认交给模型自己决定

到这一步，系统失去的已经不是“准确率”，而是刹车能力。

所以 Control 这层并不只属于长任务。哪怕整个任务只有“读代码 → 改文件 → 跑测试 → 提交”四步，系统也仍然要回答：测试失败后还能不能提交？进入人工确认后还能不能继续改文件？到了预算上限后，是不是还要再放行一次？

这些问题听起来都不复杂，但它们共同在问同一件事：系统到底有没有能力在关键时刻，把下一步拦下来。

二、为什么 Agent 时代又把“控制面”重新变成了核心问题

在传统软件系统里，控制和执行通常是分开的。

数据库能执行查询，但不能自己决定要不要升权限。 工作流引擎能推进流程，但不能绕过审批节点。 CI/CD 能自动发布，但前提是状态满足预设规则。 也就是说，执行能力是一回事，谁能批准执行继续发生 是另一回事。

Agent 把这两件事重新缠在了一起。

因为模型既能提出方案，又能调用工具，还能根据结果继续判断。它天然会让系统产生一种错觉：既然它能推理，那是不是也可以顺便决定什么时候继续、什么时候暂停、什么时候宣布完成？

这正是问题开始的地方。

OpenAI 在 Codex 的公开工作流里，已经把复杂任务明确写成 plan → implement → validate → repair 这种闭环结构，而不是让模型沿着一条自由流动的上下文一路往下推。这个设计本身就在说明一件事：真正可靠的 agent 执行，不是让模型始终主导节奏，而是把节奏放回受控结构里。

同样地，越来越多平台开始重新强调 control plane 这个词，也说明行业正在把一个老问题重新抬回核心：当 Agent 真正开始执行、审批、调用外部系统时，系统不能只关心“能不能做”，还必须关心“谁来决定它现在还能不能继续做”。

所以 Control 不是 Agent 时代一个附属模块，而是 Agent 真正走向生产之后，被重新抬回系统核心的问题。

三、Harness Control 不是什么

要写清楚 Control，先得把它和几个很像、也最容易混掉的东西分开。

1. Control 不是 Planner

Planner 负责提出“接下来可能怎么做”。 Control 负责决定“这些动作现在到底允不允许做”。

前者是建议，后者是放行。

模型可以同时承担一部分 planner 的职责，但它不应该独占 control 的职责。否则它既是提案者，又是批准者，最后就会把“我觉得可以继续”误当成“系统允许继续”。

2. Control 不是 Task Loop

Task Loop 解决的是：一个任务如何持续跑下去，如何拆解、恢复、继续。 Control 解决的是：在任何时刻，系统如何保留“下一步”的决定权。

说得更直接一点：

• Task Loop 管的是时长
• Control 管的是主权

没有 Task Loop，复杂任务会跑不长。 没有 Control，任务就算能跑很久，也只是一个会无限继续的循环。

3. Control 不是 Prompt 里的规则提醒

如果一个系统真的要求“高风险动作必须人工确认”，那这不应该只是 Prompt 里的一句话。 Prompt 只能表达希望，Control 必须提供硬约束。

控制层真正起作用的时刻，恰恰是模型已经很想继续的时候。那时如果系统只是“提醒它一下”，基本等于没控制。

4. Control 也不是单纯的 Guardrails

Guardrails 更偏输入输出检查。 Control 要管的是整个执行过程中的推进权。

一个系统可以有很强的安全过滤，却仍然没有控制层。因为它或许能过滤危险内容，却依然回答不了：

• 当前状态是否合法
• 这一步能不能被放行
• 异常出现后谁来接管
• 人工审批前能不能继续往后跑

这些都不是单点 guardrail 的问题，而是持续在线的执行控制问题。

四、Control 真正管的是四种权力

如果要把 Control 压缩成一个最可复用的框架，我会用四个词：放行、暂停、恢复、终止。

这四个词比“编排”“调度”“治理”更底层，也更适合解释生产系统为什么需要控制层。

1. 放行权：不是动作能不能做，而是它「现在」能不能做

很多动作在系统里本身都是合法能力。 改文件合法，调工具合法，发请求合法，提交 PR 也合法。

真正的问题不在“能不能做”，而在“现在****该不该做”。

测试失败后再提交，动作本身仍然是 git push； 进入审批节点后继续改配置，动作本身仍然是 write_file； 预算耗尽后再跑一次工具，动作本身仍然是合法调用。

**Control 的第一层价值，就是把“能力存在”与“当前可放行”分开。**开头那个“测试已经失败，却还允许继续提交”的失控瞬间，本质上就是放行权已经从系统手里滑走了。

2. 暂停权：在关键节点，系统必须能真的把手刹拉起来

暂停不是提醒，不是弹窗，不是“建议稍后继续”。 真正的暂停，是执行链路在这里被正式挂起，直到外部条件满足再恢复。

这也是为什么 OpenAI Agents SDK、LangGraph、Mastra 这些框架都开始把 human-in-the-loop 做成“能暂停、能审批、能恢复”的原生能力，而不是让开发者自己拼几段逻辑。 LangGraph 的 interrupt() 很有代表性：图执行到节点时，系统会真的停住、保存状态，然后等待外部输入。这说明暂停权不是 UX 细节，而是控制层的第一等能力。 同样地，开头那个场景里如果系统已经进入“测试失败”或“等待人工判断”，却还允许继续改文件，本质上就是暂停权没有真正生效。

3. 恢复权：出了问题以后，从哪里重新开始

暂停之后如果没有恢复能力，系统只会变成“停住然后重来”。 真正成熟的控制层，要能回答：失败后从哪里恢复，恢复后哪些状态继续有效，哪些必须重置，哪些动作不能再次放行。

Temporal 的 durable execution 之所以在这类场景里重要，不是因为它更像 AI，而是因为它把每一次推进都写进事件历史，失败后能从正确的位置恢复，而不是让系统重新猜自己走到哪了。

换句话说，**恢复权解决的是执行连续性，防止控制层在失败时失忆。**如果系统每次失败后都只能“从头再来”或“继续往前蒙”，那它其实没有恢复权，只有碰运气。

4. 终止权：什么时候系统必须说“到这里为止”

最不成熟的 Agent 系统，通常都默认“只要还能继续，就继续”。 但生产系统必须保留一种能力：在某些条件触发时，不再继续补救、不再继续尝试，而是正式终止。

比如：

• 超过总预算
• 连续失败超过阈值
• 命中高风险策略
• 审批被拒绝
• 状态已经进入不可继续的终态

终止权不是悲观，而是成熟。 因为系统真正可控，不是因为它总能往前走，而是因为它知道什么时候必须停。 如果测试已经失败、审批已经被拒绝、预算已经越界，系统却还默认“再试一次”，那不是韧性，而是终止权缺失。

五、为什么状态机会重新变重要

Control 一旦讲到落地，迟早会回到一个看起来很“老派”的词：状态机。

第一次接触 Agent 时，状态机很容易被嫌“笨”。模型都已经会推理了，为什么还要把流程写成一堆状态和跳转？

答案很简单：因为推理只能告诉你“接下来可能做什么”，状态机才能告诉你“什么跳转在系统上是合法的”。

拿一个简单的代码 Agent 来说，系统通常至少会有这些状态：分析中、修改中、验证中、等待审批、完成、回滚、终止。

有了这些状态，系统就能明确：

• 分析中 不能直接跳 发布
• 验证失败 不能直接跳 提交
• 等待审批 期间不能继续改文件
• 终止 之后不能再恢复成“继续执行”

工程系统之所以要状态机，不是因为工程师喜欢复杂，而是因为没有合法状态转移，控制层就无从落地。

如果说 Environment 讲的是边界，Control 讲的就是边界内的合法运动规律。 从四种权力的角度看，状态机真正保证的是两件事：哪些动作可以被放行，哪些状态已经进入必须终止或必须等待的区间。

六、人工审批为什么不是“人类介入”，而是「控制权回收」

人机协作常常被写成一个体验问题，好像只是“让人参与一下”。 但从 Control 的视角看，审批根本不是“参与”，而是控制权回收。

一个动作一旦具备下面几种特征，它就不该再默认由模型独占推进权：

• 后果不可逆
• 风险半径突然变大
• 影响外部世界
• 有明显合规责任
• 当前信息不足以自动判断

这时系统需要做的，不是给模型一条更长的提醒，而是正式把执行权从模型手里收回来，交给人或策略系统。

从四种权力的角度看，审批的本质就是：系统先行使暂停权，再把是否恢复放行的权力交给人。

一旦这样理解，你就会发现很多所谓“human in the loop”实现其实并不是真的控制层，只是在执行链路旁边加了一个通知系统。

七、生产级 Control 最终会长成什么样

当你把上面这些东西放到一起看，会发现成熟的 Control 层不会只是一个 if-else 集合，也不会只是一个长任务调度器。它更像一个持续在线的控制面。

这个控制面至少要回答四类问题：

• 当前状态是什么
• 这一步能不能被放行
• 现在该暂停、恢复、还是终止
• 这一步的最终决定权属于模型、系统，还是人

这也是为什么越来越多平台开始用 control plane 这个词。因为它抓住了问题本质：模型可以负责生成动作，执行层可以负责把动作跑起来，但真正让系统可控的，是管理这些动作何时被允许发生的那一层。

在 Harness 的语境里，这正是 Control 的位置。

它不替模型思考，也不替工具行动。它负责的是更底层的事：在任意一个时刻，系统是否还保留着“下一步”的决定权。说得再压缩一点，就是：放行、暂停、恢复、终止，这四种权力是不是还在系统手里。

最后

一旦系统没有保留放行权、暂停权、恢复权和终止权，Agent 的每一次执行都会慢慢滑向同一种状态：模型不只是执行者，也变成了批准者、裁判和节奏控制者。那时系统看起来还在运行，实际上控制已经丢了。

Environment 讲的是它活在什么样的世界里，Task Loop 讲的是长任务如何跑下去，而 Control 真正讲的是：系统有没有能力在关键时刻把“下一步”重新握回自己手里。

模型决定 Agent 能想多远，而 Control 决定系统****什么时候该让它继续，什么时候必须把它停下来。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】