智能代理编排

一个智能体到底做什么，一步一步来看

跟着一张订单从头走到尾会更容易理解，因为「智能体」这个词掩盖了每一步其实有多平常。

一封邮件进来：「Hi bro，跟上个月一样，但要 20 箱不是 12 箱，周四送。」基于规则的系统对此束手无策。智能体先弄清是谁发的 —— 拿地址去比对你的客户名单，并注意到这位发件人此前已经下过十一次单。

接着它需要知道「跟上个月一样」是什么意思，于是查出该客户上一张订单，找到三个品项。它把邮件提到的那一项数量调整过来，另外两项原样保留。然后核对三项的库存，发现其中一项少了六个单位。

这正是脚本会崩溃、或者悄悄做错事的地方。智能体面临一个选择，而价值就在这个选择里：它把两个有货的品项确认下来起草订单，把缺货那一项连同实际可用数量一并标出，再写一句话说明它做了什么、为什么这么做。然后它停下来，等人。

这就是全部的循环 —— 读取、判断、执行、检查、拿不准就上交给人。在有人上班之前把这个循环重复四十遍，就是我们真正在做的系统。里面没有任何魔法。真正难的是判断，尤其是判断什么时候不该自己判断。

决定成败的五件事

几乎每一个让人失望的智能体项目，都是栽在这五件事之一，而其中没有一件是模型本身。

第一，目标是否清晰。「在订单上用 AI」不是目标，是愿望。「读取每一封通过邮件或 WhatsApp 到达的订单，起草录入系统，拿不准的都标出来」才是目标，因为你能判断它有没有做到。如果这句话我们写不出来，就不开工。

第二，工具权限。智能体的能力上限，就是它被允许接触的东西。如果订单系统没有 API，也没人愿意给我们一个登录账号，再聪明也没用。决定工期的通常是这件事，而不是 AI 本身的工作。

第三，数据质量。智能体必须认得出你的客户。如果同一个买家以略有差异的名字存了三次，它在这三条上都会犹豫，而你会断定这个智能体不可靠 —— 真正的问题却在客户表。这就是为什么数据管道总是成为第一个项目。

第四，上交机制的设计。智能体做的最重要的一件事，是意识到自己该停下来。事先定义清楚「拿不准」是什么意思 —— 陌生客户、对不上的价格、超出常规范围的数量 —— 正是这一点把它从风险变成资产。

第五，可观察性。当有什么看起来不对时，你需要看到智能体当时是怎么想的。它做的每个决定都用大白话记录下来，主管可以直接读它的推理，而不是靠猜。解释不了自己的智能体，在真实业务里活不下来。

该给它多大权限，以及什么时候放宽

我们被问得最多的不是「它能不能做这个」，而是「万一它做错了怎么办」。答案是：你不会在第一天就交出权限；权限是随着它挣得信任而逐步放宽的，而且你随时可以再收回来。

第一阶段，智能体起草，人来审批每一条。这看起来像是白忙一场，其实不是：审批四十份草稿要二十分钟，而手工敲四十张订单要两个半小时。你已经拿到了大部分好处，同时还能在建立信心的过程中看着每一个决定。

几百张订单之后，你会清楚地知道它在哪些情况下稳定正确。通常是老客户按常规数量订购熟悉的品项 —— 而这占了大部分的量。这一类可以自动放行，其余仍然停下来等人。

这个门槛是业务决定，不是技术决定。有的客户让金额低于某个数的自动通过，其余复核。有的按客户来分：熟悉的那二十个账户自动通过，其他都查。两种都行，都由你来定，而且一个下午就能改。

我们不会做的，是凭「大概没问题」就把不可逆的操作交给智能体无人值守地执行。付款、取消订单、直接发邮件给客户，这些都留在人的后面，除非你明确决定改变。

运行成本，老实说

有两笔成本，性质不同。开发是一次性的。运行成本按笔计算，值得在你下决心之前就搞清楚，因为它决定了随着规模变大，这笔账还成不成立。

每当智能体读取一张订单并对它进行推理，这次推理会由 AI 服务商按进出的文本量计费。对订单处理来说，实际数字是每单几分钱，不是几块钱。按每天四十单算，相对于它替代的人力，这是可以忽略的零头。

它不再是零头的场合，是量极大而单笔价值极低的情况。如果你每天要处理一万个小件，按件做 AI 推理就是用错了工具，传统的规则系统既更便宜也更可预测。你到了那个区间，我们会告诉你。

另一笔运行成本是维护，而且它是真实存在的。系统会变，供应商会改版门户，你自己的流程也会调整。请预留一点持续的关注，而不是假定建好的系统会永远正确。长期顾问服务涵盖这一块，但你也可以坏了再叫我们。

在它接触任何真实系统之前，是怎么测试的

我们建的智能体没有一个是第一天就见你的生产系统的。测试的顺序比开发本身更重要，而且这部分讲出来通常最让客户安心。

第一阶段是回放。我们取过去几个月的几百张真实订单 —— 都是你已经处理过的，所以正确答案是已知的 —— 然后在关闭一切写入的情况下让智能体跑一遍。它改不了任何东西，只能说出它「本来会怎么做」。然后我们把它的判断和实际发生的对比。

这个对比才是真正工作的开始，因为分歧在两个方向上都有价值。有时是智能体错了，我们就去调它。但相当多的时候是智能体对了，而当初人工录入的那条是错的 —— 数字写颠倒、价格过期、忙碌的早晨漏了一行。客户常常对自己原本的出错率感到意外，而这也让最终的对比更公平。

第二阶段是影子运行。智能体与你的团队并行处理真实订单，仍然什么都不写。每天早上，都有人可以看到它对着真实收件箱本来会怎么做，包括那些确实棘手的消息。这样跑一两周，多数顾虑就消了，而且它会暴露出历史数据里永远没有的边缘情况 —— 回复三个月前旧邮件的客户、把手写便条拍照发过来的订单。

到这时它才开始写入，而且一开始只是没人非接受不可的草稿。如果任何时候数字看着不对，关掉它只是一个开关，你的团队照旧运作，因为什么都没被拆掉。这是刻意的：在自动流程挣得资格之前，我们不拆掉手工流程。

出问题的时候会怎样

每一个自动化系统最终都会出故障。可控的故障和昂贵的故障之间的差别，完全在开发阶段就决定了，所以值得把这些系统的行为讲明白。

第一条原则是：智能体要大声地失败。如果它连不上你的订单系统、价格查询返回空、或者它看到的订单数量离常态远得可疑，它就停下来并通知人。它不会拿着残缺信息继续跑，也不会猜。悄无声息的失败 —— 系统看起来跑了两周，实际上什么有用的东西都没产出 —— 正是我们最下力气去防的那一种结果。

第二条是：一切可回退。操作都记录得足够详细以便撤销，而且在早期阶段智能体写入的是草稿而非既成事实。万一有一批错的通过了，你可以准确查出哪些记录在什么时候被动过，而不用凭记忆去还原。

第三条是：手工通路永远不消失。你的团队保留手工处理订单的能力，智能体不可用只是不方便，而不是停工。任何让你在上线当天就废掉旧流程的顾问，优化的是他的账单，不是你的周二。

实际上，多数故障都很无聊。供应商改了页面版式。API 密钥过期了。有人重命名了表格里的一列。这些会触发一封邮件，某人花二十分钟，系统继续跑。人们真正担心的那种戏剧性故障 —— 智能体自信地干了件灾难性的事而无人察觉 —— 恰恰就是审批关卡和日志存在的意义。