第 14 章 · 让智能体真的动起来
老板先看这一句： 别被「能聊两句」的演示骗了——会答话不等于会办事。你该问团队一句:这个智能体除了聊天,到底能替我们办成哪一件真事(查订单、改资料、回客户)?更要问清楚:它办这件事的边界怎么守、出错谁拦。这几块积木(RAG / Agent / Skill / MCP)的装配质量,直接决定它落地后是帮你省钱还是给你惹祸,这一章就是帮你看懂该盯哪里。
会答话,不等于会办事
有个做保险的团队,兴冲冲给我看他们的成果:一个问答机器人,你问「重疾险和医疗险有什么区别」,它答得头头是道。他们说:「智能体做好了,该上线了。」
我问了一句:「那客户说『帮我查一下我这单能不能加保、加多少钱』,它能查吗?」——不能。它只会「答话」,不会「办事」。它没法去查这位客户的保单、没法调核保规则、没法把结果填回系统。它是个会背书的学生,不是个能干活的员工。
一个真正动起来的智能体,得能感知、能决策、能调工具、能拿到真实结果。 这一章,我用 Agent 落地工程师的视角,把智能体动起来要用到的几块积木——RAG、Agent、Skill、MCP、多智能体——串成一个最小闭环。
说明一下:这一章只讲交付时你要关心什么,不讲每块积木的内部实现。那些属于「底盘怎么造」,是姊妹篇的活儿,我会用 📎 把你精准指过去。作为 Agent 落地工程师,你要会装配和判断,不必从零造每一个零件。
把场景换到跨境家居老板老陈身上也一样:客户问「我那批货到哪个港口了、能不能改收货地址」,一个只会背条款的机器人照样答不上——它得真去查物流系统、调订单接口才算办成事。
最小闭环:五块积木
把一个能办事的智能体拆开,通常是这五块:
一、给它知识——RAG。 让智能体能查企业自己的资料(产品手册、条款、历史工单),而不是只靠模型脑子里那点通用知识。
- Agent 落地工程师要关心的:数据从哪来、够不够新、答案能不能给出处。答得好不好,一大半取决于喂进去的资料质量,而不是检索算法多高级。
- > 📎 技术深读:切片、向量化、检索与重排的工程实现,见 Harness Agent Book · 第 10 章。
作为 Agent 落地工程师,RAG 你不必自己造,但有三件和「交付质量」直接相关的事要盯住——它们决定了知识问答准不准、稳不稳:
- 切分方式决定召回质量。 同一份文档,按定长切、按语义切、按标题结构切,检索效果差很多。优先按结构切,长文再补语义切,比无脑定长强得多。
- 向量库不必一步到位。 起步用 pgvector 或轻量方案就够了;等数据量和 QPS 真上来,再考虑 Milvus / Weaviate 这类分布式方案。别为 PoC 过度选型。
- 单一向量检索不够,加关键词 + 重排。 纯向量检索容易漏掉精确匹配(如产品型号、专有名词);混合检索(向量 + 关键词)再加一层重排序,能把 Top 结果质量明显拉起来。
二、给它脑子——Agent。 让它能「想一步、做一步、看结果、再想下一步」,而不是一次性吐个答案。这个「感知→决策→行动→观察」的循环,是智能体和普通问答的分水岭。
- Agent 落地工程师要关心的:它会不会绕圈、会不会失控、每步动作能不能被记录。要给循环设上限(最多想几步),别让它无限打转烧钱。
- > 📎 技术深读:Agent 的本质与 ReAct 循环,见 Harness Agent Book · 第 1 章 与 第 2 章。
三、给它手艺——Skill。 把「怎么做某类事」的固定套路,封装成可复用的技能包,让智能体每次都按你验证过的方式做,而不是每次即兴发挥。
- Agent 落地工程师要关心的:哪些高频、要求稳定的动作该固化成 Skill,减少不确定性。
- > 📎 技术深读:Skill 的定义与组织方式,见 Harness Agent Book · 第 6 章。
四、给它手脚——MCP / 工具。 让它能真的去查系统、调接口、写数据——从「说」变成「做」。开头那个保险例子缺的就是这块。
- Agent 落地工程师要关心的:开放哪些工具、每个工具的权限边界、危险动作(写库、扣款、对外发)有没有卡人审。工具给多了会失控,给少了办不成事。
- > 📎 技术深读:MCP 协议与工具接入,见 Harness Agent Book · 第 4 章。
五、让它们协同——多智能体。 当一个智能体扛不下所有活,就拆成几个各管一段,再编排它们协作(比如一个负责检索、一个负责起草、一个负责审校)。
- Agent 落地工程师要关心的:是不是真需要多个。别为了「架构酷」硬拆——多智能体调试更难、成本更高,单个能搞定就别拆。
- > 📎 技术深读:多智能体编排的基本模式,见 Harness Agent Book · 第 15 章。
把五块拼成一个能办事的闭环
单看积木没意义,拼起来才是智能体。用开头那个保险场景走一遍闭环:
客户:「我这单能不能加保、加多少钱?」
↓
Agent(脑子):拆解任务——先查保单,再对核保规则,再算保费
↓
MCP/工具(手脚):调保单系统,拿到这位客户的真实保单
↓
RAG(知识):检索核保规则条款,判断是否符合加保条件
↓
Skill(手艺):按固定的保费测算套路算出金额
↓
Agent 汇总 → 🧑 人工确认(涉及金额,人审门)→ 回复客户你会发现,五块积木各司其职,而 Agent 落地工程师的价值不在造某一块,在把它们按业务流程装配起来、并在对的地方(金额)插上人审门。这就是「让智能体真的动起来」的实际样子。装配的分层结构,可对照附录 C 的架构模板。
从 Agent 装配图，升级为 AI 业务能力闭环
Agent 能调用工具，只说明“技术链路能跑”。要进入经营流程，还必须把六个业务要素一起装进去：
| 要素 | 在闭环中的位置 | 必须留下的证据 |
|---|---|---|
| 经营结果 | 定义为什么要运行这条链路 | 指标、基线、目标、负责人 |
| 真实流程 | 明确触发、等待、异常和上下游 | 现状流程图与目标流程图 |
| 企业上下文 | 提供 ERP 状态、规则、知识和历史案例 | 数据来源、版本、权限与更新机制 |
| 人机分工 | 决定 AI 提示、建议、判断或执行到哪一步 | 人审点、升级条件、责任矩阵 |
| 系统工具 | 让 AI 查询、创建、更新或触发业务动作 | 工具白名单、最小权限、审计日志 |
| 持续评估 | 根据结果和失败样本继续改进 | 评估集、运营看板、复盘节奏 |
业务触发 → 获取可信上下文 → AI 分析或决策 → 调用系统执行
↓ ↓
人工处理异常 ← 记录结果与反馈 ← 持续评估这才是最小完整闭环。缺少其中任何一项，Agent 都容易退化为一次演示、一个孤立工具，或者一条没人敢真正使用的自动化流程。
Agent 落地工程师视角:装配比造零件更重要
作为 Agent 落地工程师,面对这五块积木,记住三条判断原则:
- 够用就好,别堆满。 不是每个项目都要五块全上。很多 PoC 只需要 RAG + 一两个工具就够。先满足场景卡,别炫技术栈。
- 在边界处插人审,不在中间插。 人审门要卡在「产生真实后果」的那一步(对外发、写库、涉金额),中间环节让它自己跑,别处处打断。
- 每一步都要可观测。 智能体动起来后最怕「黑箱」——它到底调了什么、为什么这么答,得能查。这既是调试的基础,也是上线门禁(第 23 章)的硬要求。
让它动起来，也要防它乱动
智能体一旦能调工具、查系统、写数据，风险就不再只是「答错一句话」。Agent 落地工程师至少要盯住五类失败模式：
| 风险 | 表现 | 控制动作 |
|---|---|---|
| 工具过权 | 只该读数据，却给了写库、删除、发外部消息权限 | 最小授权、工具白名单 |
| 循环失控 | Agent 一直思考、一直重试，烧 token 不出结果 | 步数上限、超时、成本阈值 |
| 提示注入 | 用户或网页内容诱导 AI 忽略系统规则 | 输入隔离、工具调用前校验 |
| 输出直通 | AI 生成的错误内容直接发给客户或写入系统 | 高风险动作人审、输出校验 |
| 数据串租户 | A 客户的问题检索到 B 客户资料 | 租户隔离、权限过滤、审计日志 |
可观测也要具体到字段。一次完整执行，至少应该能查到：
| 环节 | 要记录什么 |
|---|---|
| 输入 | 用户、租户、输入摘要、脱敏结果 |
| 检索 | 命中文档、版本、相似度或规则命中 |
| 推理 | prompt 版本、模型版本、循环步数 |
| 工具 | 工具名、参数摘要、返回状态、耗时 |
| 人审 | 谁确认、确认时间、修改了什么 |
| 输出 | 最终答案、是否发送、成本、trace id |
这些记录不是为了写漂亮日志，而是为了三件事：出错能定位，评估能复盘，上线门禁能通过。
📍 场景示例：老陈的内容工厂 Agent 自己跑完一单 Listing
老陈的 120 个 SKU 里，一个四语（EN/DE/FR/ES）Listing 原来靠 2 名文案手工写，出 1 个要 2–3 天，月产约 40 个还严重跟不上。FDE 给他装了个「内容工厂 Agent」：Agent 自己感知「本周要上新 5 个落地灯」→ 调 RAG 查产品手册和品牌 voice → 调翻译工具出四语文案 → 套模板生成 Amazon/独立站/TikTok 三版素材，最后卡一道人审再发布。循环一旦设上限、工具权限收紧，就既能自己跑、又不乱发。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 单 Listing 产出 | 2–3 天（2 名文案） | 半天（Agent 跑 + 人审 20 分钟） |
| 月产 Listing | 约 40 个 | 约 120 个 |
| 多平台分发 | 人工搬运 | Agent 一次生成多版 |
| 风险点 | 机翻味、品牌 voice 漂移 | 人审门卡在发布前 |
老板决策点： 问清楚 Agent 自己跑到哪一步、发布前是不是有真人在守门——别让「能自己跑」变成「没人看就发出去」。 ——对应 → L3
常见坑
- 把「会答话」当「会办事」。 只做了问答就宣布完工,缺了工具这只手,办不成实事。
- 给智能体开太多工具。 权限给满、无边界,一旦失控后果严重。按需最小授权。
- 循环不设上限。 Agent 无限打转,烧钱又不出结果。必须设步数/超时上限。
- 为了酷硬上多智能体。 单个能搞定的事拆成一堆 Agent,调试成本翻倍、收益为零。
- 不留可观测。 智能体成了黑箱,出错查不到、上线过不了门。
本章产出
老板行动点： 问团队一句话:这个智能体除了聊天,到底能替我们办成哪件真事?再追问办这件事的边界谁守、出错谁拦。别为「看起来能聊」的演示批预算,要为「真能办事且有护栏」的效果批预算;该省的算力可以省,该守的人审门和权限边界一分都不能省。
往交付包里放一张「智能体最小闭环装配图」:
针对你的场景,画出这一单业务要用到哪几块积木(RAG / Agent / Skill / MCP / 多智能体),按业务流程把它们串成闭环,并标出人审门插在哪一步。技术实现照 📎 深链去 Harness 书补,你负责的是这张装配图本身。可与 附录 C 的分层架构对照填写。
成熟度自检
- [ ] 我能为一个场景选出需要的积木,并装配成一个能办事的最小闭环(→ L3)
- [ ] 我能说清每一步该关心什么、人审门插在哪、如何保证可观测(→ 迈向 L4)