一个 AI 干一件小事，串起来就是一整条业务流水线

我见过最典型的一个失败：老板看别人家 AI 很厉害，决定做一个「全能业务助手」——能查价、能对单、能催款、能回客户邮件、还能出报表。项目做了三个月，钱花了不少，最后发现：每个功能都能演示，没有一个能真用。

问题不在 AI，在做法。你一上来就要一个「全能员工」，可你连它第一件事都还没让它干好。

正确的顺序反着来：先让一个 AI 只干一件小事，跑通了，再串起来。

一、每个 Agent 只干一件事

想想你们公司怎么带新人的。你永远不会让一个新来的业务员第一天就接全流程：先让他学查价，查熟了再学对单，再学催款，最后才让他独立面对客户。

Agent 也一样。给它一个小到不能再小的职责：

• 查舱 Agent：收到船期表，自动确认舱位和到港时间
• 询价 Agent：根据运价表，自动生成报价单草稿
• 对单 Agent：核对提单和报关单字段，标出不一致
• 催款 Agent：按账期自动提醒客户付款，语气分层

每个 Agent 只干一件事，意味着它的提示词简单、边界清楚、出错范围小、改起来容易。它干不好，你一眼就能看出来是哪个 Agent 的问题，而不是对着一个「全能助手」猜哪里坏了。

二、单点先跑通，再串联

单点 Agent 跑通之后，下一步才是把几个 Agent 串成一条流水线。

货代里最典型的一条线：客户询价 → 查舱 → 报价 → 对单 → 催款。

• 询价 Agent 收到客户邮件，提取目的港、货量、时间要求
• 自动把信息推给查舱 Agent，查可用舱位
• 查舱结果回来，询价 Agent 生成报价单草稿，发人工确认
• 成交后，对单 Agent 接手核对单据
• 账期到了，催款 Agent 自动提醒

每一步都是上一轮的「单点 Agent」，只是现在它们开始互相传递信息。人还是那个拍板的人，但重复的搬运、查询、核对、提醒，都有人干了。

为什么要这个顺序？因为串联的前提是每个环节都靠谱。一个环节的 Agent 老出错，串起来就是整条流水线出错——出错了你还不知道是哪一环。单点先跑通，串的时候才有信心。

三、串联之后，团队协作的方式也变了

单点 Agent 各自干活的时候，它们之间要靠人传话。串联之后，Agent 之间开始直接传数据，人退到关键节点做判断。

这时候你得到的不是「一个更聪明的全能 AI」，而是一条可观测、可调整的流水线：

• 哪一环慢了，单独看那一环的 Agent
• 哪一环质量不行，单独改那一环的提示词
• 想加一个新环节（比如自动补发舱单提醒），单独加一个 Agent 挂上去

这比一个「什么都会一点」的巨型 Agent 好维护得多。业务同事也能看懂：这条流水线由几个小 Agent 组成，每个是干什么的，一目了然。

四、货代场景怎么起步：三周计划

别想太多，从一条最痛的小线开始。给一个参考节奏：

• 第 1 周：选一个最重复、最不依赖人判断的活（比如查舱、催款提醒），配一个 Agent 跑起来
• 第 2 周：让业务同事真用起来，收集哪里不准、哪里烦，改到大家愿意用为止
• 第 3 周：再加第二个单点 Agent，尝试让两个 Agent 传一次数据

三周之后你手里不是「一个演示」，而是一条已经有人在用的两环节流水线。这时候再谈扩不扩，心里就有底了。

五、适用边界

这个方法适合重复任务多、环节清楚、边界分明的业务——货代、物流、贸易这类行业天然合适。它不适合的任务是：需要大量创造性判断、结果没法验收的活，那种别硬做成 Agent。

我还没有完整答案的问题：串起来的 Agent 越来越多之后，Agent 之间传数据的可靠性怎么保证、哪一环该加人工确认节点。目前的办法是「每个 Agent 干完都留个结果记录给人看」，但这套在环节很多时会不会撑不住，我还要更多实战来验证。

继续读：怎么像有开发团队一样去提需求、去建设 Agent？；搭一个 AI 员工，不用写代码；货代询价工作流怎么拆，见货代询价：从人工到 Agent 工作流。