Agent 不是工具，是边界

我们习惯把 agent 当成一个更强的工具。

工具的特征是：你给它目标，它执行；你评估它，它交付。它不质疑目标本身，也不重新定义任务。锤子不会问"你确定要钉这颗钉子吗"，编译器不会说"这段代码的意图我理解错了"。

但当我们开始用"agent"这个词时，变化往往被低估了。真正的变化不在能力，而在边界的位置。

一、工具止于接口

一个工具与人的关系是清晰的：接口之内是它的职责，接口之外是你的世界。你调用它，它返回结果；结果好不好，由你在接口之外判断。

这种清晰带来一种安心：出错时，你知道该怪谁。

但 agent 不一样。agent 被赋予了目标，却没有被指定路径。它需要在环境中观察、决策、行动，并根据反馈调整。于是问题出现了——

它的"职责边界"在哪里？

如果它为了完成你给的目标，自主选择了一个你没预料到的手段，这个手段造成的后果，算谁的？

这不是一个假设性的伦理题。它每天都在发生：一个自动化脚本为了"保证服务可用"重启了一台机器，而这台机器上正跑着某个不可中断的任务。

接口没变，边界却移动了。

二、Agent 的真正特征是"未被完全指定"

我们可以给 agent 一个更诚实的定义：

Agent 是一个其行为未被完全指定的系统，它被允许在给定目标下自行决定如何行动。

这个定义里最关键的词是"未被完全指定"。不是"智能"，不是"自主"，而是规格的不完整。

传统软件是完整规格的：给定输入，输出确定。Agent 不是。它的行为空间是开放的，你无法穷举它可能做什么。你只能约束它、引导它、监控它。

这就意味着：agent 的引入，本质上是在系统里开了一个口子——一个你无法在部署前完全封闭的口子。

而这个口子，就是新的边界所在。

三、边界不在代码里，在判断里

既然 agent 的行为无法被完全指定，那么控制它的方式就不能只是"写更多规则"。

你需要的是判断：什么该做，什么不该做；什么可以自主，什么必须请示；什么错误可以容忍，什么错误必须中止。

这些判断无法被完全编码，因为它们依赖于情境。同样的动作，在不同上下文里含义完全不同。一个 agent 删除一个文件，可能是清理缓存，也可能是摧毁证据。

所以，设计一个 agent 系统的核心工作，不是写更多功能，而是划定判断的边界：

• 哪些决策它可以自己做？
• 哪些必须交回给人？
• 出错时，谁来承担，如何回溯？
• 它的行动空间，在哪里被真正封住？

这些问题没有技术上的唯一解。它们是设计问题、组织问题、伦理问题。

四、我们其实一直在造 agent，只是没承认

回头看，自动化系统早就在做 agent 的事：调度器决定哪个任务先跑，推荐系统决定给你看什么，风控系统决定是否拦截一笔交易。

它们都没有被完全指定。它们都在目标下自行决策。它们都在某个边界内行动，而那个边界往往不是被明确划定的，而是在事故之后才被发现的。

Agent 这个词的流行，与其说是技术的飞跃，不如说是一个承认：

我们早就在造这样的系统了，只是以前叫它"自动化"，现在我们愿意正视它带来的边界问题。

五、结语

把 agent 当工具，会让你低估它。

工具的问题是"它能不能做到"；agent 的问题是"它做到了什么，这算谁的"。

前者是工程问题，后者是边界问题。

而边界，从来不是代码能单独解决的事。

• 关于自动化系统"规格不完整"导致责任归属困难的讨论，参见相关 AI 伦理与自动化责任文献。
• 关于"边界"作为设计与治理问题而非纯技术问题的思路，参见人机交互与算法治理领域的相关论述。