有界任务原则：为何受约束的AI代理优于开放式的

Source: Dev.to

引言

Claude 在两周内发现了 Firefox 的 22 个漏洞——其中包括 14 个高危漏洞。
人们常常关注模型能力，但真正的教训是 受限任务。

成功来源于 明确的范围、明确的输出格式 和 清晰的成功标准。
代理并没有被要求“提升 Firefox 的安全性”；它被赋予了具体的参数、特定的表面区域以及对发现的精确定义。

这一原则适用于你构建的每一个 AI 代理。

为什么大多数代理会失败

大多数代理失败并不是因为模型质量，而是任务规范定义不充分。
当一个任务可以有多种解释时，代理会选择一种解释——往往是错误的——并为之优化，而用户想要的却是完全不同的东西。

模糊任务规范的症状

• 代理循环时间超出预期
• 输出看起来“合理”，但偏离了核心要点
• 不同运行产生截然不同的结果
• 代理在错误的时机（任务进行中而不是之前）提出澄清问题

四个必备字段

在每个任务定义中加入这四个字段——无论是提示词、current-task.json，还是 SOUL.md 指令：

{
  "scope": "What is in bounds. Be explicit about what is NOT in scope.",
  "output_format": "Exactly what the result should look like.",
  "done_when": "Observable condition that defines completion.",
  "success_criteria": "How a human will evaluate whether the output is correct."
}

• Scope（范围） 防止代理做超出界限的工作。它回答：“边界在哪里？”
• Output format（输出格式） 防止解释漂移。它回答：“‘完成’在结构上是什么样子？”
• Done when（完成条件） 防止无限循环。它回答：“代理何时应该停止？”
• Success criteria（成功标准） 关闭反馈回路。它回答：“我们如何判断它是否成功？”

对照 Anthropic/Firefox 审计

注意这里没有出现：“让 Firefox 更安全”。那是愿景，而不是任务规范。受限版本产生了 22 条可操作的发现。

受约束代理的好处

• 减少思考该做什么的时间
• 产出更一致的结果
• 出错时快速失败（而不是漂移）
• 运行成本显著降低

在生产环境中表现最好的代理并不是工具最多的，而是任务定义最清晰的。

任意代理的快速检查清单

1. Scope（范围） – 能否用一句话说明范围？（如果不能，范围太模糊）
2. Output format（输出格式） – 能否在代理运行前描述输出的样子？（如果不能，格式未定义）
3. Done condition（完成条件） – 能否毫不含糊地说明代理何时停止？（如果不能，缺少完成条件）
4. Success criteria（成功标准） – 你会知道输出是否错误吗？（如果不能，缺少成功标准）

如果无法回答全部四项，请在添加新工具或功能之前收紧任务规范。

资源

经过实战检验的受限任务模式配置——包括 current-task.json 模板和 SOUL.md 升级规则——可在 Ask Patrick Library 中获取：

askpatrick.co/library