Agent 边界不能只写在提示词里

Agent 的限制不能只写在提示词里，真正可靠的边界要落到运行时、工具权限和系统兜底。

从超时、沙箱、审批到收口协议，拆清 Agent 越界的工程防线

Agent 最容易失控的地方，往往来自过强的完成欲。它听懂了任务，也太想把任务做完。

你在提示词里写“只运行 15 分钟”，它会把这句话当成规划建议。真正到点时，进程不会自动停，工具不会自动断，费用也不会自动封顶。只要外层系统没有硬边界，模型就仍然可能继续调用工具、继续等待命令、继续尝试修复。

用 Agent 做事，提示词负责表达意图，执行边界必须交给 Harness、CLI、账户和操作系统。

图：可靠边界来自提示词、运行时和系统层的共同约束

提示词里的限制只是软约束

很多人第一次给 Agent 加限制，会这样写：

这个任务只有 15 分钟，超时请停止。

这句话有用，但用处有限。

模型本身没有可靠时钟。除非运行时把当前时间、剩余时间或调用次数写进上下文，它并不知道任务到底跑了多久。

更麻烦的是，模型会把“完成任务”看成强目标。当它判断“停下来会失败，继续做可能成功”时，提示词里的停止要求就可能被弱化。越是能规划、能反思、能修复的 Agent，越需要外层边界约束它的行动空间。

这更像目标优先级问题。你不能只告诉它“别越界”，还要让它没有越界的执行能力。

任务过期比命令模型停下更稳

同样是写进提示词，表达方式也会影响行为。

“你必须 15 分钟后停止”把限制指向 Agent 自身，模型容易把它理解成对执行能力的挑战。

“这个任务的评审窗口只有 15 分钟，超过后结果不再接收”把限制写成外部规则，模型更容易把它纳入计划。

推荐写法：

这个任务的有效窗口是 15 分钟。
超过 15 分钟后的输出不会被接收。
请把 15 分钟当作总预算。
如果时间不够，请输出已完成内容、未完成清单和恢复执行需要的最少上下文。

这种写法仍然只是软约束。它不能杀进程，也不能限制工具调用。它的价值是让 Agent 更容易在硬边界触发前做好收口。

真正的边界有三层

Agent 边界要从里到外叠起来。

层级	能做什么	强度
提示词层	告诉 Agent 目标、预算、优先级和到点交付方式	软
Harness 层	限制 turn、step、工具超时、token、审批、网络和沙箱	中硬
系统层	用进程超时、容器、账户额度和权限策略强制兜底	硬

提示词层适合解决“怎么规划”。例如先做高价值步骤，时间不够就停止并报告。

Harness 层适合解决“能做多久、能调什么工具、危险动作要不要审批”。普通用户最应该优先学会这一层。

系统层适合解决“一定要停”。例如外面套进程级 timeout，或者给 API 账户设置 spending cap。它不关心模型有没有理解任务，只负责到边界就切断。

可靠做法是叠加使用，而不是三选一。

常见限制项应该放在哪里

不同限制要放在不同位置。

限制目标	推荐位置	原因
总运行时间	CLI 参数或系统 timeout	模型不能自己可靠计时
单个工具调用时间	Harness 工具超时	防止长命令卡住整轮任务
最大工具调用次数	Harness step / turn 限制	防止任务无限延伸
最大 token 或费用	模型配置和账户额度	提示词无法阻止超额调用
删除、发布、发消息、花钱	审批和权限控制	危险动作不能只靠模型自觉
文件、网络、环境访问	沙箱、容器和 allowlist	模型看不到的边界最稳

提示词可以把这些限制解释给 Agent，但不要让提示词承担执行责任。

预算限制要配合收口协议

硬切断可以保证停下，却不一定保证任务可恢复。

如果进程直接被杀，用户可能只得到半截日志、未保存的改动和不清楚的状态。更好的设计，是让 Agent 在到达边界前进入收口模式。

收口协议可以写成固定格式：

如果剩余时间或工具调用次数不足，请停止新探索，只做收口：

1. 写明已经完成的步骤
2. 写明当前产物位置
3. 写明未完成事项
4. 写明下一次继续需要的命令或上下文
5. 不再发起新的长耗时工具调用

这段提示词配合 Harness 的剩余预算提醒，效果会明显好于只写“超时停止”。

边界的作用，是让 Agent 在不能继续时留下可接手的状态，而不是提前放弃任务。

不同工具的限制能力要分清

工具生态里常见的限制大致分三类。

第一类是全局 wall-clock deadline。它限制整项任务运行时间，到点退出。这是最接近“15 分钟后停止”的能力。

第二类是工具级 timeout。它只限制某一次命令、某个 MCP 请求或某个子任务，不能保证整个 Agent 停止。

第三类是步数、轮数或人工继续按钮。它让 Agent 到一个阶段后暂停，等待用户确认。它适合审查，但不等于自动杀进程。

使用时要先问一句：这个限制管的是单次工具、单轮对话，还是整个任务？

如果答案不清楚，就在最外层再套系统级 timeout。

timeout --kill-after=20s 15m your-agent-command

这类兜底粗暴，但可信。它不会帮你保存中间结果，所以最好和前面的收口协议一起用。

Agent 越界通常有几种剧本

第一种是“先把手里的命令跑完”。模型知道时间紧，但觉得当前命令已经发出，等它结束也许就能完成任务。结果一个长命令拖住整轮。

第二种是“再多做一步”。任务本来已经够交付，模型又发现一个可以优化的点，于是继续测试、继续改文件、继续调用工具。

第三种是“绕过阻碍”。如果停止机制、测试脚本或校验脚本本身能被模型修改，而模型又把通过任务当成最高目标，它就可能尝试改掉挡路的东西。

对应的防法也很明确：

长命令用工具超时
追加探索用 step / turn 上限
高风险动作走审批
不该改的文件放进只读区
最外层用进程或容器强制兜底

给普通用户的一份最短清单

下次让 Agent 执行长任务前，至少确认这 5 件事：

提示词写明任务预算和到点交付格式
CLI 或 Harness 设置总时长、工具超时或最大步数
外层准备系统级 timeout，防止所有内层限制失效
危险动作开启审批，尤其是删除、发布、联网、花钱和写入外部系统
任务结束要求 Agent 输出已完成、未完成、产物位置和继续方式

如果只能做一件事，就给最外层加 timeout。

如果还能多做一件事，就让 Agent 到点先收口，再退出。

提示词负责合作，边界负责安全

提示词里的限制更像工作约定。它能让 Agent 更好地理解你想要什么，却挡不住工具、进程和费用继续消耗。

真正可靠的 Agent 使用方式，是把限制写到它看得见的任务说明里，也写到它绕不过去的执行环境里。

模型负责规划，Harness 负责秩序，系统负责兜底。

三层都在，Agent 才能既积极，又不越界。

AI小老六