实现 Agent 的方法，其实只有八种

一、先纠正一个最普遍的误解

很多人第一次做 Agent 都会有个误解，以为"接上工具"就是让模型去调自己的 API。事实是——模型从头到尾都只在吐字，它根本不碰网络，也不碰数据库。

真实的链路是这样的：

模型做的事只有一件：输出一段文本，说明它想调哪个工具、传什么参数。真正去查库、发 HTTP、改数据的，是你自己写的执行器。

这个认知很重要，因为它决定了工作量落在哪一侧："让 AI 能干活"这件事，九成的工程量在你这边，不在模型那边。

二、换一个分类角度

网上讲 Agent 分类的文章很多，主流是按架构分：ReAct、Plan-and-Execute、多智能体、树状搜索……但这个分法有个问题——它讲的是"AI 内部怎么想"，不回答"我该做什么"。

换个角度会清楚很多：

你能提供给 AI 的载体就那么几种。提供哪一种，就得到哪一种 Agent。

按"你提供什么"划分，目前所有实现手段可以穷举成八种：

三、八种方式逐一拆解

1. 提示词

本质：用自然语言规定它的身份、边界和输出格式。

怎么做：就是 system prompt，四件套——角色定义、硬性规则、输出结构、少量示例。零代码，改文字就能改行为，迭代最快。

什么时候够用：只需要它"说"，不需要它"做"。客服 FAQ、文案生成、翻译、意图分类。

坑：

• 规则写太多会互相冲突，模型开始顾此失彼。
• 对"不要做 X"的服从度，明显弱于"要做 Y"。用正向表述代替禁令。
• 长对话里最早写的规则会被后面的内容稀释，关键约束要反复重申或放到最后一轮。

2. 接口 / 函数

本质：把你系统的能力声明成模型能读懂的「函数」，由模型自己决定调哪个、传什么参数。这是让 AI 能动手的唯一途径。

怎么做：导出一份工具清单，每一项包含名称、一句话用途说明、参数定义（类型、必填项、可选值）。模型返回调用意图，你的执行器查表找到对应方法执行，把结果回灌。

这一步最常见的错误，是把接口 1:1 暴露成工具。你有 40 个 REST 接口，就给它 40 个工具——这是最差的做法。

工具要按用户意图收敛，不是按数据库表：

GET  /device/list          ┐
GET  /device/status/{sn}   ├──→  query_device    查列表、状态、实时数据
POST /device/command       ──→  control_device  下发指令，需二次确认
GET  /alarm/list           ──→  query_alarm     查告警记录

四条核心原则：

1. 一个工具 = 一个业务动作，不是一张表、不是一个接口。
2. 描述要写"什么时候用它"，不是"它返回什么字段"。模型靠语义匹配来选择，描述写得像接口文档，它就选不准。
3. 同时暴露的工具控制在十几个以内。堆几十个上去，选择准确率会明显下降。超出就按场景切分子集，只注入当前相关的。
4. 返回结果必须裁剪。接口原本返回 200 条记录，原样丢给模型就是几万 token。要分页、聚合或摘要。

什么时候用：需要 AI 操作你的业务系统——查数据、下指令、改状态。

坑：

• 写操作没有二次确认。涉及下发指令、删除、退款这类动作，必须先把"即将执行什么"回显确认，不能模型说执行就执行。
• 权限裸奔。AI 调用必须携带当前用户身份走正常鉴权，否则用户问一句"把所有人的订单给我看看"就真给它了。
• 错误信息不讲人话。别把 500 和堆栈丢给模型，返回"设备 A 当前离线，无法下发指令"，它才能据此调整策略。

3. 知识库（RAG）

本质：提问时先把相关资料片段检索出来，塞进上下文。

怎么做：文档切块 → 向量化 → 存入向量库 → 提问时按相似度召回 top-k → 拼进提示词。解决的是"模型不知道你的业务事实"。

什么时候用：产品文档、内部规范、历史工单、合同条款这类领域知识问答。

坑：

• 切块粒度不当。太碎丢上下文，太大噪音多，通常要按语义边界切而不是按字数切。
• 只做向量检索。中文场景下，向量召回对专有名词、编号不敏感，要混合关键词检索。
• 召回片段不带来源标识，模型会把几段不相干的内容揉成一个看似合理的答案。

4. 流程骨架

本质：把任务步骤写死在代码或可视化画布上，模型只在需要判断的节点上发力。

怎么做：节点 = 调模型 / 条件分支 / 调工具 / 人工审批；边 = 执行顺序与条件。你在画布上连好线，运行时就照这条线走。

什么时候用：业务路径明确、出错代价高、需要审计留痕。工单流转、审批、告警处置这类流程。

坑：

• 路径一变就要改流程，灵活性差。所以要在设计时就想清楚哪些步骤是稳定的。
• 把本该由模型临场判断的地方也写死，系统会变得很僵。判断该由流程兜底还是模型决策，是这一层最核心的设计题。

5. 代码沙箱

本质：给它一个能执行代码的环境。

怎么做：容器隔离，模型生成代码 → 执行 → 把输出（含报错）还给它 → 它自己改，直到跑通。

为什么有效：数值计算、日期处理、批量文本清洗、图表绘制这类任务，让模型"心算"的错误率远高于让它写段代码去算。会写代码的 Agent，比只会思考的 Agent 靠谱一个量级。

什么时候用：需要精确计算、批量数据处理、生成文件或图表的场景。

坑：安全隔离必须做，别让沙箱碰生产网络；必须有执行超时；文件读写边界要明确。

6. 操作界面（Computer Use）

本质：让模型看屏幕截图、移动鼠标、敲键盘，像人一样操作软件。

什么时候用：目标系统只有网页或客户端，没有可调用的接口。这是最后手段。

坑：慢、贵、脆弱——页面布局一改就可能崩，而且出错时很难定位是"看错了"还是"点错了"。能用接口解决的，绝不用这个。

7. 子智能体

本质：把"一个 Agent"本身当成可调用单元，拆分职责。

怎么做：编排者负责拆解任务 → 分给若干执行者 → 每个执行者带独立上下文各自干活 → 最后汇总或交叉验收。

什么时候用：任务可并行、需要多视角交叉验证、或者单条上下文已经长到影响判断质量（拆开隔离反而更准）。

坑：

• 角色一多，通信开销和误差放大往往超过收益。 2 到 3 个角色通常是甜点区，五个以上的多智能体系统多半是在给演示效果做加法，不是在给产品做减法。
• 角色之间传递的信息如果没有结构化约定，会退化成一场冗长的聊天。

8. 反馈数据

本质：把成功的操作轨迹或人工标注拿去训练，把"怎么用工具、怎么规划"从提示词搬进模型权重。

什么时候用：任务高频、形态固定、对成本和延迟敏感。典型如固定的数据提取、固定的字段填报。

坑：门槛最高——需要足够的数据量、需要评测体系、迭代周期长；环境一变（接口改了、业务规则改了）就得重训。绝大多数项目一辈子用不到这一层。

四、这八种不是选择题，是叠加关系

真实项目里从来不是八选一，而是自下而上叠积木：

                记忆         ← 记住上次做过什么
              代码沙箱       ← 能写代码、能算数、能处理文件
             流程编排        ← 按你画好的路径走，不会乱跑
            知识库           ← 能查你提供的资料，不靠瞎猜
          接口 / 函数         ← 能动手操作你的系统
         提示词              ← 有角色、有规则、有输出格式
        大模型               ← 会聊天，仅此而已

底座永远是大模型，每往上加一层，能力增强，成本和风险同步上升。所以正确的心态是：从最下面开始，哪层不够用再加哪层，能不加就不加。

五、三种典型配方

实际落地时，多数项目落在这三种形态之一：

• 能写死 → 走流程骨架（稳健型），最可靠；
• 写不死 → 给工具让它自己判断（标准型），最灵活；
• 根本不需要动手，只回答问题 → 纯知识库（轻量型），最省事。

至于代码沙箱、操作界面、子智能体、微调这四种，属于"上面三种不够用了才加上去"的增强件。其中后两种，大部分项目一辈子用不到。 六、几个高频的坑

1. 一上来就做全能 Agent 能用一个确定性流程解决的，不要上自主循环。可靠性和成本差一个数量级。

2. 权限与审计缺位 AI 能访问的数据范围，必须和当前用户的真实权限一致。所有调用都要留审计日志：谁、什么时候、通过 AI 调了什么、参数是什么、结果如何。出事时要能复盘。

3. 没有终止条件 必须设硬上限——轮数、token、时间、预算。没有上限时，死循环不是异常而是常态。

4. 用模型代替确定性代码 该用 if-else 判断的地方别交给模型。模型适合处理模糊、开放、需要理解语义的环节；确定性的分支、校验、计算应该用代码。

5. 只盯准确率，忽略成本 一个 Agent 任务的 token 消耗，常常是单次问答的几十到几百倍。成本必须和效果一起评。

七、写在最后

Agent 这个词被讲得很玄，但落到工程上，它就是一个问题：

你愿意把哪些能力交给它，又愿意给它多大的自主权。

八种实现方式，其实就是"能力"和"自主权"两个维度上的不同配比。你给的载体越具体（固定流程、固定接口），系统越稳但越僵；你给的越少（只给一句提示），越灵活但越不可靠。

想清楚这一点，剩下的都是选型和工程量问题，不再是玄学。