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 不是 PlannerPlanner 负责提出“接下来可能怎么做”。 Control 负责决定“这些动作现在到底允不允许做”。前者是建议后者是放行。模型可以同时承担一部分 planner 的职责但它不应该独占 control 的职责。否则它既是提案者又是批准者最后就会把“我觉得可以继续”误当成“系统允许继续”。2. Control 不是 Task LoopTask Loop 解决的是一个任务如何持续跑下去如何拆解、恢复、继续。 Control 解决的是在任何时刻系统如何保留“下一步”的决定权。说得更直接一点Task Loop管的是时长Control管的是主权没有 Task Loop复杂任务会跑不长。 没有 Control任务就算能跑很久也只是一个会无限继续的循环。3. Control 不是 Prompt 里的规则提醒如果一个系统真的要求“高风险动作必须人工确认”那这不应该只是 Prompt 里的一句话。 Prompt 只能表达希望Control 必须提供硬约束。控制层真正起作用的时刻恰恰是模型已经很想继续的时候。那时如果系统只是“提醒它一下”基本等于没控制。4. Control 也不是单纯的 GuardrailsGuardrails 更偏输入输出检查。 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 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】