构建Agent指南

type

status

date

slug

summary

1. 什么是Agent

💡

先回答一个问题，什么不是Agent？

传统软件帮助用户简化并自动化流程，但还需要用户操作

一个应用如果只接入了模型，不让模型主导工作流执行，例如聊天机器人，那么也不算Agent

💡

Agent 是一种可以独立替你完成任务的系统。

核心特征有两个：

有判断力：Agent 依托大语言模型管理工作流并作出决策，可以判断流程是否完成，是否需要纠正，是否需要交还给用户操作

可调用工具：Agent可以调用多种工具与外部系统交互以获取上下文或执行操作，过程中会遵循明确定义的安全边界

2. 什么时候需要构建Agent

💡

非Agent工具不能做到的事情，就是需要构建Agent的时候

以识别风险支付订单为例：传统规则引擎通过核对条件，按照预设规则标记；LLM Agent更像经验老道的交易员，结合上下文，交易细节来判断，即使这笔订单没有明显违反固定规则

在评估Agent应用价值时，应当优先考虑难以自动化，且传统方法受阻的流程，包含不限于：

复杂决策：需要细致判断，处理例外的场景，例如退款审批

规则难维护：当规则库庞大复杂，更新易出错时，例如供应商安全审查

高度依赖非结构化数据：需要解析自然语言，读取文档或与用户对话的场景，例如保险理赔

3. Agent 设计基础

3.1. 三大组件

Agent包含三大核心组件：

模型：为Agent提供推理和决策能力的大语言模型

工具：Agent可调用的外部函数或API，用来执行具体操作

指令：明确规定Agent行为方式与安全边界的规则

3.2. 如何选模型

💡

核心原则：选最适合而非最强大的，满足要求前提下模型越小越合适

选择模型一般遵循以下步骤:

建立评价体系，找到Baseline（基线）

先用最优模型确保性能指标符合要求

在保证性能指标符合要求的前提下，用更小的模型来替换，进而优化成本和延迟

3.2.1. 什么是Baseline

一套评价体系，代表业务能接受的最低标准是什么，例如识别准确度不得低于 80%

通过基线可以快速筛选出来不符合要求的方案有哪些，再从符合要求的方案里面进行优化，提升迭代速度

3.3. 定义工具

根据使用方式可以大致分为几类：

传统API接口：提前告知模型有哪些API，需要输入什么参数，能够达成什么效果，模型在运行过程中通过代码环境进行调用并接受结果

MCP：适用于AI的“特定API”，在构建一个mcp的时候就会提前设定好需要告知AI的信息，模型调用和接受信息会更方便

coding：直接通过编码实现特定工具需求并达成预期效果

根据AI需求还可以分为三类:

数据工具：为AI提供必须的数据，例如搜索网页，查询交易库等

行动工具：AI可以调用并执行相应动作，例如发送邮件

编排工具：把一个Agent封装成工具，支持被另一个Agent调用

3.4. 配置指令

💡

高质量提示对所有 LLM 应用都重要，对 Agent 更是关键。 明确的指令可减少歧义、提升决策质量，使工作流更顺畅、错误更少。

实践参考：

把现有 SOP、客服脚本或说明文档拆分成 LLM 易读的步骤

引导 Agent 先拆解任务，再逐步执行，降低歧义

让每一步都对应具体动作或输出，比如“调用 API 获取订单号

预判常见问题：信息缺失、用户提问跑题等，用条件分支处理

4. Agent编排

4.1. 单Agent系统

💡

为同一个 Agent 添加工具，能处理多种任务，同时保持复杂度可控，方便评估与维护

每新增一个工具都会增强功能，而不会过早迫使你拆分成多 Agent 架构

Agent的工作通常表现为一个循环过程，会不断执行操作，直到满足退出条件，一般有几类条件：

触发了最终输出工具，输出的内容满足特定标识

模型不再调用任何其他工具，而是直接回复用户

出现了错误，模型判断无法自主解决

循环次数达到了上限

如何想要保持单Agent的低复杂度，最好使用【提示词模板】，即输入的提示词主体不变，里面的核心参数通过变量进行设定

这样当出现新的情况时，不需要改动工作流，只需要修改变量即可

4.2. 什么时候需要拆分Agent？

💡

核心原则：能单个就单个，单个无法解决的时候再考虑多个

增加Agent虽然能分离职责，但会带来额外的复杂度；当系统出现以下情况的时候再考虑拆分Agent：

复杂逻辑：如果提示词里面包含了大量的条件判断，并且提示词模板难以维护的时候，可以拆分Agent

工具过载：当一个Agent的工具池里面数量过多或者类型用途存在重叠的时候，并且通过优化命令页无法解决调用工具错误的情况，可以考虑拆分Agent

4.3. 多Agent系统

多Agent系统有两类通用模式，管家模式和去中心模式

4.3.1. 管家模式

一个中心管家通过调用工具的方式协调多个专长Agent

管家不会丢失上下文或控制权，而是能在合适时机把任务智能分派给对应 Agent，并轻松整合结果，形成连贯交互。 这样既保证了流程顺畅统一，又能在需要时即时调用各专长 Agent 的能力。

示例场景（以多语言翻译为例）：

管家 Agent (manager_agent)：

指令：若用户请求多语言翻译，就调用对应工具。
工具列表：将 spanish_agent / french_agent / italian_agent 封装为工具，分别命名 translate_to_spanish、translate_to_french、translate_to_italian。

子 Agent（专长 Agent）：各自掌握具体翻译能力，内部可有自己的工具与 guardrail。

运行流程：

用户输入“Translate 'hello' to Spanish, French and Italian for me!”

manager_agent 解析到需要三种语言 → 依次调用三个子 Agent 工具；

汇总结果后一次性回复给用户。

4.3.2. 去中心模式

多个Agent交替控制，依据各自专长交接任务与控制权

交接是一种单向传递，一个Agent把任务委托给另一个Agent

在 Agents SDK 中，交接被实现为一种工具或函数；当某 Agent 调用交接函数时，系统立即在被交接的目标 Agent 上启动执行，并同步最新的对话状态

示例场景（客服分流实现）：

triage_agent：首问路由；根据意图选择交接对象。

technical_support_agent / sales_assistant_agent / order_management_agent：三位专长 Agent ，各自拥有独立工具与指令。

交接方式：triage_agent 调用 handoff 工具，将控制权与上下文转移给最合适的专长 Agent。

4.3.3. 对比总结

维度	管家模式 (Manager pattern)	去中心化模式 (Decentralized pattern)
核心机制	单一“管家” Agent 调用子 Agent（封装为 tool）并负责结果汇总与对话窗口统一	多个平级 Agent 通过 handoff tool 单向交接控制权与上下文
优势	- 用户只接触一个接口，体验一致 - 任务分派逻辑集中，可统一做日志、评测与 guardrail - 子 Agent 易复用，像模块化函数	- 并发友好，无中心瓶颈；任何 Agent 可立即与用户互动 - 职责与数据域天然隔离，权限暴露最小 - 新增/替换专长 Agent 对整体影响小
劣势	- 管家成为单点：高并发或复杂汇总时可能成为性能瓶颈 - 所有上下文需回流到管家，增加延迟	- 缺乏统一出口，结果整合需另行设计 - 交接链过长易导致上下文漂移、调试困难
适用场景	- 需要统一对话窗口，例如多语言翻译、综合问答机器人 - 高度依赖集中决策/审计：金融交易、合规审批 - 子任务需要结果汇总再返回用户	- 客服分流：技术支持/销售/订单处理并行接棒 - 多系统、多权限域，要求最小权限暴露 - IoT 或分布式执行，节点自主完成后即可结束
复杂度 & 维护	- 管家逻辑复杂度随业务增长线性上升 - 子 Agent 作为独立模块易测试	- 每个 Agent 简单，但整体调试需追踪交接链 - 需设计失败回滚或超时重试策略
典型风险控制	管家一处集中添加 Guardrail / 人工复核	每个 Agent 单独配置 Guardrail，高风险动作可在交接点触发人工审核

5. 安全控制-护栏（Guardrails）

在任何基于 LLM 的系统里，护栏至关重要，必须与稳健的鉴权、严格的权限控制及常规安全措施配合使用

5.1. 护栏类型

Guardrail Type	作用	示例
Relevance classifier相关性分类器	检测提问是否跑题	“帝国大厦多高？”→ 标记为无关
Safety classifier安全分类器	识别越狱 / 注入风险	诱导暴露系统提示的请求
PII filter个人信息过滤	阻止输出不必要的 PII	模型回答前先审查
Moderation内容审核	拦截仇恨、暴力、骚扰	调用 OpenAI Moderation API
Tool safeguards工具风险分级	按可写入性/金额等打分并决定是否人工复核	退款 API ≥ $1 000 需暂停审核
Rules‑based protections规则过滤	长度限制、黑名单 regex、SQL 注入拦截	禁止含“DROP TABLE”
Output validation结果校验	保证与品牌价值一致	检查措辞是否符合指南