让 AI 主动执行任务它越能干越要先画好 3 条「停止线」摘要主动执行是 Agent 最被吹捧的能力也是最容易翻车的环节。本文从真实踩坑场景出发分析 Agent 循环为什么天然没有「适可而止」的概念拆解边界失控、验收缺失、成本失控三种典型模式给出一套可直接落地的「3 条停止线 验收清单」约束设计并用一个完整的周报素材整理案例演示前后差异。结论先行AI 主动执行的价值不取决于它声称自己多能干而取决于你给它画的那几条停止线。一、一个反直觉的现象最浪费时间的恰好是它一直在跑先看三个真实场景。场景一有人让 AI 整理一组选题材料。任务下发时没说做到哪算完也没说最终交付什么。结果 AI 越补越多——从标题补到大纲从大纲补到图片建议最后还「贴心」地附上了三种排版方案。看起来极其努力实际上能用的东西没几样用户还得从头筛一遍。这种努力更接近自我感动。场景二有人用按量计费的 Agent 产品跑任务。任务描述只有一句话Agent 开启「莽夫模式」穷举所有可能路径吭哧吭哧一通猛算。等用户发现方向不对时几千积分已经烧掉了。事后复盘问题不在模型——在于「你思路越清晰话说的越明白就越省钱你为每一个没想清楚的地方都得真金白银地交学费」。场景三来自 B 端产品物联控制业务里要配置一个情境场景涉及场地、人员、设备、规则四个模块传统模式下用户要在四个管理页面间来回跳转。有的产品为此引入 AI 助手让用户只录入规则要求助手自动完成跨模块配置。方向是对的——这类「强逻辑、跨模块、步骤明确」的复杂任务确实适合 AI 接手。但落地时同样要回答那三个问题配置到哪一步算完成、每一步的结果谁验收、误配了设备规则谁来兜底。B 端场景的特点是权限线天然更粗——设备控制规则配错是会出安全事故的所以这类产品无一例外都做了「AI 出初稿 人工确认后才生效」的双闸设计本质上就是本文第四节要讲的方法论。三个场景有一个共同的结构任务的发起者以为「让 AI 自己跑」就是省时间结果最大的时间和钱开销恰恰产生在它「一直在跑」的那段。在技术社区混久了会发现这类抱怨的表达高度一致「让 AI 主动执行任务靠谱吗」「AI 自己跑偏了怎么拉回来」「为什么 Agent 跑了半天产出不能用」。注意这些问题的共同点——大家问的都不是「AI 能不能干」而是「怎么让它干到点就停」。┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ 任务模糊下发 │ -- │ Agent 持续延伸 │ -- │ 产出远超需求 │ │ 没说停在哪 │ │ 看起来很努力 │ │ 可用部分≈0 │ └────────────────┘ └────────────────┘ └────────────────┘矛盾的转移很清晰上一代工具的问题是「不会做」这一代 Agent 的问题是「不知道在哪停」。前者逼你学会用工具后者逼你学会设计任务。二、原理剖析Agent 循环里没有「完成」这个内建概念要理解为什么 AI 会一直跑得先看清 Agent 的底层结构。一个 AI Agent 的核心是一个循环感知接收任务与环境信息→ 规划拆解目标、选择工具→ 行动调用工具或模型执行→ 观察获取执行结果→ 迭代。Anthropic 在其工程实践总结《Building Effective Agents》中指出多数场景下简单的组合模式prompt 检索 工具调用比复杂的多 Agent 编排更有效——但无论简单还是复杂这些模式共享同一个前提停止条件必须由外部注入。无停止线 有停止线 ┌──────────────┐ ┌──────────────┐ │ 接收任务 │ │ 接收任务 │ └──────┬───────┘ └──────┬───────┘ v v ┌──────────────┐ ┌──────────────┐ │ 规划行动 │ │ 规划行动 │ └──────┬───────┘ └──────┬───────┘ v v ┌──────────────┐ ┌──────────────┐ │ 观察结果 │ │ 观察结果 │ └──────┬───────┘ └──────┬───────┘ │ v │ ┌──────────────┐ └── 继续 ──┐ │ 命中停止线 │ │ └──────┬───────┘ v │ 是 → 交付 倾向于「再补一点」│ 否 → 继续左边的循环里模型每一轮观察完都要自己判断「够不够好」。而这个判断存在系统性的偏差第一生成式模型的训练倾向是「补全」而不是「止步」。面对一个模糊的目标它默认的方向是把结果做得「更完整」——更多细节、更多备选、更多「附加价值」。你不说停它就把一个模糊任务一直往外延伸。这不是 bug是它的出厂设置。第二「看起来合理」与「可用」是两套度量。Agent 的自我评估建立在生成结果的自洽性上逻辑通不通、格式全不全而用户的验收建立在任务的经济性上我下一步能不能直接用。这两套度量之间没有换算关系。Lilian Weng 在《LLM Powered Autonomous Agents》一文中对 Agent 能力边界的分析出发点正是这种「声称完成」与「实际完成」之间的鸿沟。第三按 token 计费的结构放大了失控的代价。传统软件跑偏了顶多费 CPUAgent 跑偏了每一步「再补充一下」都是真金白银。这就是场景二里几千积分消失的机制解释——不是 Agent 突然变蠢了是你没设护栏而护栏缺失在计费模型下会被无限放大。停止条件的技术形态有三档可靠性依次递增落地成本也依次递增形态实现方式可靠性适用软约束prompt 约定在任务描述里写「20 分钟内、只交 3 个方案」中——模型大概率遵守但长任务中会漂移一次性、低风险任务硬约束循环代码在 Agent 循环代码里写死步数/时间/交付检查高——代码不撒谎自建 Agent、可改代码权限闸工具层危险工具调用前强制走人工确认最高——不依赖模型自觉任何有外溢影响的场景多数人的误区是停在第一档以为 prompt 里写了「别扩写」就万事大吉。软约束的问题是它依赖模型的自觉而模型在多轮长任务里的「记忆」会衰减越到后面越容易忘记开头的约定。真正稳妥的做法是三档叠加prompt 里说清楚给模型方向循环代码里卡死给系统底线危险动作上权限闸给业务兜底。一句话总结这一节Agent 不怕多干活它怕的是你没告诉它「做到哪就够了」。三、问题诊断三种典型失控模式把第一节的场景展开主动执行的失控可以归为三种模式。它们经常同时出现但解法不同值得分开看。失控模式典型表现根因直接代价边界失控从标题补到大纲再到配图建议越干越多停止条件未定义产出冗余人工筛选成本反增验收缺失跑完了但交付物形态不是你要的交付标准未定义返工等于白跑成本失控穷举式探索积分/token 烧穿预算与路径约束未定义直接经济损失模式一边界失控。最常见。用户说「帮我整理一下」Agent 听到的是「整理到极致」。每一轮迭代它都在寻找「还能补什么」因为补充是它证明自己在工作的唯一方式。努力与可用彻底脱钩。有个细节值得注意边界失控的产出往往「看起来质量不低」——每个部分单拎出来都像模像样这正是它危险的地方。如果产出明显粗制滥造你一眼就能判断扔掉但这种「局部精美、整体过剩」的产出会诱发你「留着以后有用」的心态于是你不仅没省时间还多了一堆要归档的鸡肋。模式二验收缺失。比边界失控更隐蔽。Agent 跑完交付了一份东西格式、篇幅、结构都对唯独不是你下游能直接用的形态——你要的是「3 个方案 1 个推荐」它给了你一份 30 页的完整报告。这时候问题根本不在执行环节在任务下发环节连人都无法准确描述目标时AI 通常只能生成一份「看起来合理」的答案。判断自己是否踩了这个模式有个简单测试拿到交付物后你的第一个动作是「直接用」还是「先改格式」只要涉及改格式说明验收标准没传达到位锅在任务描述不在 Agent。模式三成本失控。最痛。任务里一句「尽量全面」Agent 理解成「穷举所有可能」。多轮工具调用 × 每轮长上下文 × 无路径剪枝成本是指数级的。营销领域有人专门总结过两类可控的做法一类是「经验路线」先人工萃取少量高质量样本喂给模型让它模仿另一类是「进化路线」明确限定每轮生成的数量比如每组 100 条和轮次上限在优胜组基础上再迭代。两条路线的共同点恰恰是给探索画了硬边界——「全面」从来不是穷举出来的是约束出来的。有实践者总结得很到位这哪是在用 AI简直是在花钱训练自己的脑子——你思路越清晰越省钱反之每一个没想清楚的地方都得交学费。注意三种模式的共同前提它们都发生在「任务下发那一刻」而不是「执行过程中」。等你发现跑偏再拉回来成本已经沉没了。四、解决方案3 条停止线 1 套验收清单解法不是「盯紧一点」而是在任务下发前就把约束设计进去。综合多个实践者的共识可以收敛为 3 条停止线。4.1 时间线最多跑 X 分钟到点先汇报给任务设一个时间盒timebox。到点必须停下来汇报当前进度而不是继续闷头跑。价值不在于那个具体的分钟数而在于强制制造一个「检查点」——你可以在损失可控的时候纠偏。对于按量计费的 Agent时间盒同时还等于预算盒。4.2 交付线只交什么交几个明确定义交付物的形态和数量上限「只交 3 个方案和 1 个推荐不要继续扩写」「只给结论、文件位置和下一步建议」。数量约束是对抗「补全倾向」最直接的手段——上限画死了模型就会把预算花在质量而非数量上。4.3 权限线涉及外部影响的动作先问我发布内容、修改账号资料、花钱、发消息给别人——这类不可逆或外溢的动作必须先请求确认。前两条线管「干多久、交多少」这一条管「什么绝对不能自作主张」。它是把「主动执行」和「失控」隔开的最后一道闸。4.4 代码层面把停止线写进循环如果 Agent 是自己搭的停止线应该落在代码里而不是全靠 prompt 自觉。一个最小实现importtime MAX_RUNTIME_S1200# 时间线20 分钟MAX_STEPS15# 步数上限防死循环DANGEROUS_TOOLS{publish,send_message,spend_budget}# 权限线DELIVERABLE3 个方案 1 个推荐总字数 800# 交付线defrun_agent(task:str):start,stepstime.time(),0whileTrue:steps1# --- 三条停止线的检查优先级高于任何下一步规划 ---iftime.time()-startMAX_RUNTIME_S:returnreport_partial(时间线触发汇报当前进度与剩余工作)ifstepsMAX_STEPS:returnreport_partial(步数上限触发可能存在循环请人工介入)actionplan_next(task)ifaction.toolinDANGEROUS_TOOLS:ifnotask_human_confirm(action):# 权限线外溢动作先问人continueresultexecute(action)ifmeets_deliverable(result,DELIVERABLE):returnresult# 交付线达标即停关键点meets_deliverable的验收逻辑在循环外部定义4.5 节Agent 自己不能既当运动员又当裁判。4.5 验收清单在按下回车前过一遍任务下发前问自己五个问题综合实践者总结目标是否明确——输入是什么、要完成什么、最终输出长什么样三个都能一句话说清吗交付形态是否定义——「3 个方案 1 个推荐」还是「30 页报告」停止条件是否画线——时间上限、数量上限写进任务了吗是否需要先问人——哪些动作划进了权限线结果由谁验收、怎么验收——交付后我用什么标准在 5 分钟内判断「能用/不能用」第 5 条最容易被跳过但它决定了下一次任务的输入质量验收标准本身也是可以迭代的资产。另外一条被低估的实践按自己的精力波峰安排任务类型。高能量时段做需要全程在场的任务内容创作、复杂规划、重要判断低能量时段才放给 AI 自跑的标准化任务整理资料、归档、批量初筛。把「需要验收设计」的高判断任务和「可以碎片化」的低判断任务分开本质上也是给主动执行划适用边界。五、实战案例让 Agent 自动整理周报素材用一个完整案例把上面的方法串起来。任务每周五从团队的提交记录、聊天记录、文档变更里整理出周报素材。改造前真实踩坑版帮我把这周的工作整理成周报素材。结果Agent 拉取了全部 5 天的记录按天逐条总结把每条讨论的来龙去脉都展开还自作主张写了周报正文初稿、Next-Week 计划、甚至给每条配了 emoji。全程 40 分钟产出 6000 多字。用户看完的反馈是我要的不是周报是素材不是 6000 字是 20 条以内。改造后3 条停止线版整理本周周报素材。约束时间20 分钟内完成到点交付已完成部分并说明缺什么交付不超过 20 条要点每条一句话 出处按「进展/风险/待定」三类归档不要写周报正文不要扩写权限不要发消息给任何人产出只写入本地文件。验收标准我 5 分钟内能从中挑出 10 条直接用。结果12 分钟交付18 条要点三类归档清晰用户 4 分钟挑完。两次执行的时序对比改造前 用户 ----下发模糊任务---- Agent Agent 40min 越跑越远 产出 6000 字 用户 ------ 全量阅读筛选 25min ------ 产出可用素材 改造后 用户 ----下发带3条停止线的任务---- Agent Agent 12min | 检查点交付线命中(18条) | Agent ------ 18 条要点 出处 ---- 用户 用户 --4min 挑选-- 直接可用 ▲ └── 验收标准在任务里已定义挑选执行既定标准前后对比维度改造前改造后耗时~40 分钟12 分钟产出量6000 字18 条要点人工后处理重新筛一遍 ≈ 25 分钟挑选 ≈ 4 分钟可复用性每次都是赌博prompt 可固化为模板这个案例里最有价值的产出甚至不是那 18 条要点而是那段带约束的任务描述本身——它被固化成模板后每周五直接复用。约束设计是一次性成本失控是每周一次的成本。六、总结主动执行的能力一半在 AI一半在你的停止线回到开头的问题让 AI 主动执行任务到底靠不靠谱这篇文章的答案是这个问题问错了对象。靠不靠谱不取决于 Agent 声称自己多能干而取决于三个你在按下回车前就要回答的问题——它干到哪停时间线、交付线、它什么不能碰权限线、你拿什么验收验收清单。这也是评估任何 Agent 能力时的通用原则不要看它的自我描述「我已完成任务」要看它的停止条件和验收结果。一个说不清「在哪停、怎么验」的主动执行方案无论宣传得多智能都只是把失控的时点往后推了而已。反过来三条停止线画清楚之后「主动执行」才从一场赌博变成一个可复用的工程流程。最后补一个延伸观察。这篇文章通篇在讲约束设计但约束设计有个前置问题同场景下别人已经踩过哪些坑、总结过哪些停止线你从哪里知道全靠自己的试错积累代价就是场景二那种学费。更划算的输入是被真实用户验证过的实践。怎么获得这种输入一条现成的路径是让 Agent 自己去找搜索安装 Deep Skill Finder后你在布置任务时只管提需求它会在执行过程中自动检索社区里有没有对症的 Skill经你确认后安装——比如你今天要做「带停止线的主动执行」它就能把别人沉淀好的约束模板、验收清单类 Skill 直接带到你面前。相当于给 Agent 配了一个随叫随到的技能采购员你不用再靠翻文档、碰运气去补能力缺口。