AI Agent 不是聊天机器人：它多了一双能动真实系统的手

把 AI Agent 和聊天机器人放在一起比，最容易被口才误导。一个能对答如流、能写文案、能解释政策的对话系统看上去已经很强，但它交付的始终只有一样东西：文字。你问它退款政策，它复述条款；你让它去退款，它还是复述——因为它没有一双能真正伸进业务系统的手。Agent 的分界正在这里：它能把答案说出来，也能去调用一个接口、写一条记录、触发一笔操作，让现实里的状态真的改变。

Anthropic 在《Building Effective AI Agents》里给的定义很克制。它把最基础的单元称作“增强过的大模型”——一个被检索、工具与记忆武装起来的模型，能自己生成查询、自己挑选工具、自己决定该记住什么。在此之上它再区分两类系统：workflow 是“大模型和工具被预先写好的代码路径编排”，agent 则是“大模型自主主导自己的流程和工具使用、掌控自己如何完成任务”。差别不在模型多聪明。真正变的是决定“下一步调用什么”的权力：它究竟攥在写死的代码里，还是交给了模型自己。

这也解释了为什么“聊得好”和“能办事”是两种能力。对话质量考的是它说得对不对；进入真实业务，考的是它动作做得对不对、这个动作能不能被允许、出了错能不能收回。后面这三件事，聊天机器人从来不需要回答。

Agent 能动作，靠的是一套叫工具调用（tool calling，也叫 function calling）的机制。流程并不神秘：开发者预先把每个工具的名字、用途、参数结构写清楚交给模型；模型在需要时并不直接执行，只吐出一段结构化的调用请求，说明“我要调用哪个工具、传什么参数”；真正去执行这段请求、去连 Gmail、连数据库、连支付接口的，是外面的应用代码。模型负责决策，应用负责落地，中间靠这份结构化的契约对接。

工具因此不是可有可无的配件，而是决定 Agent 上限的接口。Anthropic 在《Writing tools for agents》里说得直接：工具定义值得投入和写提示词一样多的心力；参数该叫 user_id 而不是含糊的 user，工具最好把多步操作合并——与其给模型 list_users、list_events、create_event 三个零件，不如给一个 schedule_event，或者一个能一次性汇总客户信息的 get_customer_context。工具描述得像给新同事交代任务那样清楚，模型才知道自己能做什么、该怎么做。

工具一多，接口就需要标准。Anthropic 在 2024 年 11 月开源了 Model Context Protocol（MCP），用一套客户端—服务端协议统一“Agent 如何发现并调用工具”：数据方把能力做成 MCP server 暴露出来，应用方做成 MCP client 去连接，Block、Apollo、Replit、Sourcegraph 等早期采用者据此把 AI 接进真实系统。协议本身不神奇，它省掉的是每接一个系统就手写一遍胶水代码的重复劳动。

能调用一个工具，和被允许调用它，是两件事。一个 Agent 一旦拿到写入和支付的能力，它的每个动作就动着真实的钱和数据，权限边界因此是它进入业务的前提，而不是上线之后再补的补丁。Auth0 在关于工具调用的安全指引里强调一条原则：Agent 应当继承发起人身份的权限，而不是自己揣着一套独立的万能凭证；授权按最小必要发放，能只读就不给写入，把它连向服务时用的是限定范围的访问令牌，而非把用户凭证直接塞进 Agent 环境。只读的工具天然更安全，可能造成不可逆后果的写操作，则应当被单独圈出来另作处理。

这一层恰恰是很多平台最薄弱的地方，也是中国和海外企业落地时共同的堵点。字节的扣子（国内版 coze.cn 与国际版 coze.com 双轨）、开源的 Dify、阿里百炼、百度千帆都能可视化编排并调用工具，但企业从来不是扁平的：角色、部门、数据级、操作级的权限体系客观存在，Agent 接进来必须继承并适配这套结构。而细粒度的数据权限、与企业 LDAP、SSO 的对接，在多数低代码和开源框架里仍要自行实现——Dify 这类支持私有化部署的平台能把数据留在内网，却不等于自动替你管好“谁能让 Agent 碰哪张表”。选型时把“聊得顺不顺”排在前、把权限模型排在后，往往就是麻烦的开始。

权限决定 Agent 能碰什么，但边界之内它仍会出错，所以真实业务还要求三样东西：留痕、拦截、交回。

留痕是日志。每一个动作、每一次决策、每一步工具调用都要被记录下来，而且一条完整的审计记录要同时留下两个身份：发起请求的业务用户，和真正执行的 Agent。等到要复盘一次异常、或向审计者交代一个决定时，这条记录就是“事故已了结”和“事故还挂着”之间的差别。

拦截是人工批准。Anthropic 建议 Agent 在关键节点或遇到障碍时暂停、等人反馈，并提醒它的自主性会带来更高成本和错误的层层累积，因此上线前要在沙箱里充分测试、配上相应的护栏。对不可逆或超过阈值的动作——大额支付、删除数据、修改账户——同步的人工签字应当作为一条硬性策略卡在动作之前，而不是当成默认的运行方式拖慢一切。这里有个隐蔽的失效点：当人长期只负责旁观、习惯性地点“同意”，签字就退化成盖章，护栏名存实亡。要让这道闸真的管用，被放行的每一步都得经过人的判断，而不只是经过人的鼠标。

交回是交接设计。Agent 遇到自己不该独立处理的复杂情形，要能干净地把任务连同上下文一起交回给人，而不是硬着头皮给一个似是而非的答案。什么时候自己做、什么时候举手，是它能不能被托付真实业务的分水岭。

真正把 Agent 送进真实业务的，从来不是口才，而是权限怎么划、日志怎么留、什么时候把事交回给人这套设计。Klarna 的客服助手是个便于对照的例子：它 2024 年 2 月上线，一个月接下约 230 万次对话、相当于 700 名全职客服的工作量、覆盖 35 种以上语言，纯以对话质量论几乎挑不出毛病。可到了 2025 年，这家公司又重新招回人工客服。症结不在它说得好不好，而在它始终停在“说”这一侧：面对需要判断和分寸的诉求，它能解释一条退款政策，却从未被给到去执行那笔退款、去拍板一次让步的权限。缺的不是话术，是动作的授权——一个只被允许说、不被允许做的系统，无论对答多顺，都还是一张会说话的嘴，没长出那只能负责任地办事的手。

判断一个项目有没有真的跨过这道线，触发信号很具体：出现一个握着被限定范围的工具、带着人工检查点、能从头到尾跑完一条真实业务流程的 Agent——它调用工具、留下发起人与执行者的双身份记录、在该停的地方停下等人点头。反过来的失效信号也同样清楚：一个在演示里对答如流、却迟迟没被授予任何真实动作权限的“智能助手”，演示越顺，越说明卡住它的从来不是表达，而是没人敢把真实动作的权限交给它——它能被展示，却不能被托付。