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 才能既积极，又不越界。