Agent 的生产能力，首先取决于行动边界

讨论 Agent 的时候，人们很容易把焦点放在“它能不能更自主”上。但真正进入生产环境后，更关键的问题往往不是自主度够不够高，而是它是否知道自己什么时候该动、什么时候该停。

> 生产级 agent 真正缺的不是更高自主度，而是可执行的行动边界：直接回答、调用工具、停止、遗忘和求助都需要被显式建模。

最近几类素材看似在讨论不同问题：工具调用是否过度、agent 是否会在不可能任务上继续消耗、自动化系统是不是应该全自主、工具授权越多是否越好、清空上下文后反而更快解决问题。但它们指向的是同一个工程事实：模型很多时候不是完全不知道答案，而是在执行层缺少稳定策略。

关键问题不是“给 agent 更多能力”，而是“让 agent 知道每种能力该在什么边界内使用”。如果没有边界，它会在三种方向上浪费：该直接回答时调用工具；该调用工具时硬想；该承认不可完成时继续推进。授权更多 API、堆更多工具、拉更长上下文，并不会自动修好这个问题，反而可能让错误路径变得更长。

生产级 agent 需要的不是单一的自主度旋钮，而是一张行动边界表。表里至少要显式区分五类动作：直接回答、调用工具、停止执行、重置上下文、请求人类判断。每一类动作都应该有触发条件、失败条件和退出条件，而不是交给模型在对话里临场发挥。

可以把它拆成几个更具体的判断：

这件事的难点在于，它横跨模型能力、脚手架策略和产品合约。工具调用基准可以告诉我们模型何时会误用工具，abstention 研究可以告诉我们模型何时不会停手，但真正上线时，还需要产品层明确哪些任务允许自动执行，哪些任务必须暂停审批，哪些错误需要清空历史重跑，哪些状态必须交还给人。

落到工程实践里，这类问题不适合只停留在原则层面。更值得沉淀的是可以被复用的设计约束：

Agent 的生产能力不应按自主程度排序，而应按行动边界是否清楚、是否可执行、是否能在错误路径上及时停下来判断。

龙虾升职记