Agent 产品边界：什么时候该让它停下来？

今天先记住

Agent 产品边界不是“功能少做一点”，而是给系统划出清楚的责任线：它能自主推进到哪里，什么时候必须确认，什么时候只能给建议，什么时候应该拒绝继续执行。

它在大地图里的位置

今日坐标

横跨整条链路 → Agent 产品边界

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前面讲过工具、记忆、工作流、权限、评估和多 Agent 交接。今天把视角拉回整个产品：这些零件最终都要回答同一个问题，用户把一件事交给 Agent 后，系统到底承诺交付什么，又不承诺什么。

边界横跨整条链路。目标理解错了会越界；记忆拿旧了会越界；工具权限太大也会越界；没有评估就发布结果，同样会越界。

它到底是什么

Agent 产品边界是一组可执行的限制，而不是页面文案里的免责声明。

它至少包括四类线：任务范围线、权限线、风险线、完成线。任务范围线回答“这类事我能不能做”；权限线回答“我有没有资格动这个系统”；风险线回答“这一步是否需要人确认”；完成线回答“做到什么状态才算结束”。

如果边界只写在介绍页里，运行时不检查，那它只是态度表述。真正的产品边界应该能改变系统行为：继续、追问、降级为草稿、请求确认、交给人工，或直接停止。

为什么 Agent 里会用到它

Agent 比普通 Chatbot 更容易越界，因为它会把“回答”变成“行动”。普通问答答错了，最多是文本错误；Agent 如果拿着工具继续走，可能会改文件、发消息、下单、删除数据，或者把不该发布的信息推到线上。

所以产品边界不是给 Agent 绑手绑脚，而是把可控性变成产品能力。一个文档发布 Agent 可以自动写稿、检查格式、提交 Git；但如果发现 API key、私人聊天、地址或健康数据，就应该停止发布，只保留本地文件。这里的关键不是“更安全”这种空话，而是状态从 ready_to_publish 变成 blocked_sensitive_content，后续发布工具不再可用。

怎么判断它有没有用

如果一次错误行动会影响钱、账号、生产环境、隐私或外部用户，必须有产品边界，不能只靠模型“自己小心”。
如果任务只是整理公开资料、生成草稿、解释概念，边界可以轻一点，但仍要说明输出是草稿还是已执行结果。
如果用户说“帮我搞定”，系统仍然要拆开“可自动做”和“必须确认”的部分，不能把一句授权扩展成无限权限。
你可以看日志判断边界是否真实存在：越界条件出现时，系统有没有明确状态、有没有禁用后续工具、有没有留下原因。

一个小例子

txt

Input:
用户说：“生成 2026-08-02 的 AI Agent Daily，发布到文档站。”

Process:
1. 系统生成 Markdown，并检查 frontmatter、H1、日期、URL slug。
2. 扫描正文是否包含 API key、私人项目、聊天记录、地址、电话等敏感信息。
3. 如果检查通过，执行 git add / commit / push。
4. 如果检查失败，只保存本地草稿，不执行发布。

Output:
通过时：draft -> reviewed -> published。
失败时：draft -> blocked_sensitive_content，并返回本地路径。

这个例子里，边界不是“不要泄密”四个字，而是发布前的一道状态门。它能用来解释真实系统：Agent 的自主性应该被状态机、权限和确认点约束，而不是靠模型临场发挥。

常见误区

把边界当成能力弱。能停下来是生产能力的一部分，不是 Agent 不够聪明。
只限制工具，不限制目标。工具没越权，但目标本身不该执行，系统也应该拦住。
只在高风险动作前确认，不记录确认后的状态。没有审计，后面很难复盘是谁批准了什么。
把“人类最终负责”当万能兜底。产品上必须让人类能看懂、能接手、能否决。

今天自测

一个 Agent 系统至少要划出哪四类产品边界？
为什么“用户让我全自动处理”不等于系统可以执行所有工具？
如果发布前发现敏感信息，系统状态应该怎样变化，后续工具应该怎样处理？

Agent 产品边界：什么时候该让它停下来？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​