智能体使用边界

是什么，为什么存在

智能体使用边界是决定一项任务可以获得多大自主权的分界点。一侧是适合编程智能体的任务：目标已经确定、权限受到约束、结果可以检查。另一侧则是由人直接处理或用小型确定性程序完成更安全的任务。

边界取决于任务与环境，而不是模型看起来多么能干。即使模型能力很强，仍可能优化错误理解、通过获准工具暴露敏感数据、长时间探索，或者生成难以观察其正确性的改动。模型能力再强，也补不上缺失的决策或测试预言机。

人工主导处理是指由负责任的人作出后果重大的判断或执行敏感步骤。搜索、格式化、计算或起草工作仍可使用工具辅助。关键在于，不能把尚未解决的决策悄悄交给模型。

简单自动化是指普通代码遵循稳定且完整指定的规则。格式化器、模式验证器、代码修改器或固定的数据转换，通常比智能体更便宜，也更容易测试。如果所有分支都能预先写清，自适应循环只会增加变化，不会带来有用的判断力。

智能体委托适合两者之间的地带。预期结果很明确，但在代码库中找到实现路径需要搜索、工具调用和根据反馈纠错。具有复现方式、指定文件和验收测试的缺陷通常很合适；决定一项有争议的产品策略应该表达什么则不合适。

在向编程工具授予访问权、把人工流程转成自动化，以及委托任务请求扩大权限时，你都会遇到这种选择。证据变化后还要重新评估。原本安全的探索任务，一旦下一步需要发送数据、修改生产状态或作出未记录的业务决策，就可能越过边界。

三种方式，不同责任

这三种方式可以组合。人可以确定策略，确定性脚本可以迁移记录，智能体可以为改动准备测试或文档。应当按责任边界拆分任务，而不是强迫一种方式承担整个工作流。

良好的边界还要指定交接制品及其验收人。如果没有这种所有权，候选结果在工具之间流转时，就可能被误认为已经获准的结果。

这种选择不是永久不变的。一旦人解决歧义，并用示例把规则编码下来，后续案例就可能转成确定性自动化。代码库具备可靠测试和隔离工作区后，过去必须手工完成的维护任务也可能适合交给智能体。

工作原理

要在智能体看到机密或获得写权限之前作出选择。评估四个信号：不确定性、敏感性、成本暴露和验证强度。任何一个维度上的严重问题，都足以要求缩小任务或改用其他方式。

这张图是筛选流程，并不是能用总分抵消红线的评分表。如果客户意图仍有争议，较低的 token 成本也不会让决策变得适合委托。如果无法检查结果，严格的文件系统权限同样不能让自主修改变得可信。

不确定性：未知的是什么

要区分路径不确定性（route uncertainty）与结果不确定性（outcome uncertainty）。路径不确定性是目的地已达成共识，但实现路线未知，例如不知道哪个解析器负责失败行为。智能体适合处理这种情况，因为它可以搜索、检查、修改，并根据测试作出反应。

结果不确定性是合理的利益相关者可能对成功标准持不同意见。例如，决定是否允许退款例外、判断一条安全警告是否可以接受，或者在没有获准调用方的情况下设计公开 API。模型可以提出选项，但必须由负责任的人确定决策，之后才能自主实现。

把不确定性写成明确问题。「哪个模块验证这个标头？」可以通过代码库证据查明。「企业客户是否应绕过这个限制？」需要产品负责人授权，仅靠搜索代码库无法解决。

不确定性可以缩小，但未必会消失。如果调查找到了两个可能的责任模块，却无法区分，下一步应当进行聚焦观察或请求人工决策，而不是获准猜测。

敏感性：任务可能暴露或改变什么

敏感性既包括信息，也包括效果。凭据、客户私有数据、未发布的财务结果和受监管记录会产生暴露风险。生产写入、资金转移、账户删除、对外消息和公开发布即使输入数据普通，也会产生后果风险。

采用 最小权限（least privilege） ：只暴露当前受限步骤所需的资源与操作。读取夹具不需要访问整个主目录。运行单元测试也不需要网络访问或部署凭据。

只有显示真实操作时， 审批门（approval gate） 才有用。如果命令能够发布软件包或上传文件，只问「允许命令吗？」就过于含糊。审查者需要看到目标、参数、工作目录、预期效果和恢复路径。

有些步骤即使带审批对话框，仍应只由人执行。如果审批者无法检查载荷、理解效果或逆转错误，审批就很薄弱。此时应把操作缩减为可审查产物，再由人通过常规受控界面执行最后动作。

敏感性同样适用于输出。即使原文件从未离开获准目录，日志、补丁、截图和错误报告仍可能复制其中的机密。

成本：什么可能增长或重复

成本包括模型用量、经过时间、工具调用、外部 API 费用、计算资源和审查者注意力。便宜的第一步可能进入昂贵的重试循环。要限制整个运行和各个工具，并定义达到上限后的处理方式。

当解释、监督和审查智能体的成本高于直接完成小任务时，使用智能体的收益很差。修复已知行中的明确拼写错误，几乎不需要全库探索。反过来，在大量陌生文件中进行范围受限的搜索，即使最后补丁很小，也可能值得使用智能体。

成本也包括机会成本。长时间运行的智能体若占用数据库沙箱，或反复调用受速率限制的服务，就可能阻塞其他工作。任务契约应指定稀缺资源、并发限制和停止条件，而不是把 token 预算当作唯一限制。

预算还应包括失败处理。反复重试同一次被拒绝的调用或结果未变的测试，只会消耗资源而不会提供新信息，此时应触发停止条件。

验证：怎样知道任务成功了

强验证独立于智能体的解释，直接观察承诺的结果。例如回归测试、模式验证器、转换记录的精确比较、编译器结果，或者限制在允许路径内并经过审查的差异。检查必须能够拒绝一种看似合理但实际错误的方案。

弱验证只检查外观或自我报告。「代码看起来整洁」「智能体说所有案例都通过了」以及「命令打印了一些绿色文字」都不能证明所需行为。要保留命令、工作目录、退出状态、标准错误和跳过的检查。

通过的检查有其作用范围。单元测试不能证明迁移适用于真实数据分布，类型检查器也不能证明授权策略正确。把每条验收标准映射到相应证据，并把未覆盖的主张保留为人工审查项。

当验收标准确实依赖判断时，人工审查也可以成为有效证据，但必须记录审查者及其检查的材料。只有一个「已审查」标记，仍然是无依据的主张。

一张实用决策表

决策表（decision table） 可以让选择保持一致，又不会假装所有风险都能用数字精确表示。应评估实际步骤，而不是宽泛的项目标签。「更新计费系统」过于粗略；「在空的本地数据库中生成候选 SQL 迁移」才足够具体，能够分类。

不要计算各列的平均值。三个有利信号也不能抵消一次不可逆的生产操作。持续拆分任务，直到每个部分都有一个责任人、一套权限范围、一项预算和一个可检查的交接结果。

运行中的升级处理

最初的分类可能过时。新文件可能暴露个人数据，请求的命令可能需要联网，测试之间可能互相冲突，智能体也可能耗尽重试预算。应把这些观察当作边界事件，不能借此临时扩大权限。

执行前先定义升级触发条件。所需意图缺失、请求资源超出范围、证据与任务矛盾、必须产生破坏性效果，或者成本达到上限时，都应停止。把观察结果和最小的未决问题交给人。

升级处理应保留有用工作。候选差异、失败测试记录、已检查路径列表和被拒绝调用的完整内容，可以帮助人作出决定而无需重复所有探索。不能用笼统的「需要审批」消息掩盖已经发生的局部副作用。

示例

下面的示例使用确定性 JavaScript，让边界逻辑可见且可重复。生产工作流可能从表单、策略服务和测试运行器中收集这些事实，但最终授权与验证规则仍应位于模型生成的文字之外。

选择能力最低的方式

第一个分类器使用几项明确事实。它把范围受限的代码库重命名交给智能体，把稳定的批量规则交给普通代码，并把敏感且有争议的决策交给人。

条件的顺序很重要。stableRule 不能覆盖敏感、不可逆或目标没有边界的问题。因此，这个分类器比较保守：团队必须先缩小这些风险，才能进入成本更低的自动化分支。

对象字段只是关于证据的主张，不会因为代码为其命名就自动成为事实。在真实接收流程中，要询问每项主张由谁确定、依据是什么。错误的 sensitive: false 标签，可能让危险任务通过一个本身正确的分类器。

强制执行权限范围

安全提示词不能替代宿主策略。这个示例只允许访问两个代码库文件和一条指定测试命令，并且禁止网络访问。未知工具与目标都会失败关闭（fail closed）。

const policy = {
  read: new Set(["src/pricing.js", "test/pricing.test.js"]),
  write: new Set(["src/pricing.js", "test/pricing.test.js"]),
  commands: new Set(["npm test -- pricing"]),
  network: false,
};

const calls = [
  { tool: "read", target: "src/pricing.js" },
  { tool: "read", target: ".env" },
  { tool: "command", target: "npm test -- pricing" },
  { tool: "command", target: "npm publish" },
  { tool: "network", target: "https://example.com/upload" },
];

function authorize(call) {
  if (call.tool === "read") return policy.read.has(call.target);
  if (call.tool === "write") return policy.write.has(call.target);
  if (call.tool === "command") return policy.commands.has(call.target);
  if (call.tool === "network") return policy.network;
  return false;
}

for (const call of calls) {
  const verdict = authorize(call) ? "ALLOW" : "DENY";
  console.log(`${verdict} ${call.tool} ${call.target}`);
}

ALLOW read src/pricing.js
DENY read .env
ALLOW command npm test -- pricing
DENY command npm publish
DENY network https://example.com/upload

虽然测试和其他命令都通过同一个工具到达，策略仍能区分两者。它还会拒绝恰好位于代码附近的凭据文件。模型即使声称被拒绝的操作必不可少，也无法扩展这些集合。

真实的路径策略必须解析绝对路径、父目录片段和符号链接，之后才能证明包含关系。真实的命令策略应传递结构化的可执行文件与参数数组，而不是比较 shell 字符串。这些实现细节会强化此处展示的同一条边界。

要求完成证据

最后一个示例把完成定义为所有必需观察的合取。其中一次运行虽然提供了看似合理的通过测试，却缺少红绿回归证据和范围检查，因此必须返回人工审查。

const required = [
  "target test passes",
  "regression test failed before fix",
  "changed paths stay in scope",
];

const runs = [
  {
    name: "plausible summary only",
    evidence: new Set(["target test passes"]),
  },
  {
    name: "bounded verified change",
    evidence: new Set(required),
  },
];

function evaluate(run) {
  const missing = required.filter((claim) => !run.evidence.has(claim));
  return {
    decision: missing.length === 0 ? "ACCEPT" : "HUMAN REVIEW",
    missing,
  };
}

for (const run of runs) {
  const result = evaluate(run);
  console.log(`${run.name}: ${result.decision}`);
  console.log(`missing: ${result.missing.join(", ") || "none"}`);
}

plausible summary only: HUMAN REVIEW
missing: regression test failed before fix, changed paths stay in scope
bounded verified change: ACCEPT
missing: none

这个集合会记录证据是否存在，但生产交付门还必须验证证据来源。模型写出的测试通过字符串，不等于宿主捕获的进程结果。每项主张都应附带确切命令、版本、环境、退出码和输出引用。

这个交付门也说明了任务为何可能需要保持人工主导。如果没有独立检查能够表示预期行为，增加更多智能体步骤也不会让验收决策变得客观。必须由人审查结果，或者先把意图转成可执行规格。

陷阱

委托尚未解决的决策

修复方法： 把决策工作与实现工作分开。先由负责任的人批准示例、反例和边界结果，再按这些固定预期委托编码。

用智能体执行固定转换

修复方法： 直接编写代码修改器、格式规则、查询或验证脚本。如果有帮助，可以让智能体协助起草，但实际自动化应当运行经过审查的确定性产物。

把提示词指令当成权限

修复方法： 在宿主或沙箱中强制执行文件系统、命令、网络和凭据边界。测试禁止调用，并要求系统无论模型多么自信地提出请求都必须拒绝。

批准操作类别而非具体操作

修复方法： 只显示并授权一项确切操作或一条严格的可复用规则。包括工作目录、解析后的资源、外部目标、预期副作用，以及是否能够恢复。

把模型信心算作验证

修复方法： 根据宿主捕获的观察和明确审查得出完成状态。证据缺失、截断、超时或互相矛盾时应失败关闭，并指出哪项主张仍未验证。

忽略监督预算

修复方法： 开始前限制步骤数、时间、费用和审查工作量。低于这个阈值时优先直接处理；稳定工作反复出现时，改用行为可复用的确定性工具。

延伸阅读

• NIST AI 风险管理框架 Playbook
• GitHub 文档：负责任地使用 Copilot 智能体
• Claude Code 文档：安全
• Google SRE：Google 的自动化实践