当前位置：首页 > news >正文

Agent工程到底怎么做：从0到1搭建一个能落地、能调用工具、能持续优化的AI智能体系统

news 2026/5/7 16:00:18

一、先说清楚：什么是Agent工程？

Agent工程，不是简单地写一个Prompt，也不是接一个大模型接口就完事。

通俗讲，Agent就是一个“会思考、会拆任务、会调用工具、会根据结果继续行动”的AI执行系统。

普通大模型更像“聊天助手”：

用户问什么，它答什么。

而Agent更像“数字员工”：

用户给一个目标，它会判断要做什么、需要查什么、调用哪个工具、执行几步、最后把结果交付出来。

比如用户说：

“帮我分析一下最近30天用户投诉数据，找出主要问题，并生成一份改进建议。”

普通大模型可能只能给一个通用建议。

Agent工程要做的是：

1、理解用户目标。
2、判断需要查询投诉数据。
3、调用数据库或接口。
4、清洗和归类数据。
5、识别高频问题。
6、生成分析报告。
7、必要时通知负责人或创建任务。

所以，Agent工程的核心不是“让AI会说”，而是“让AI会做事”。

OpenAI 的 Agents 文档也把 Agent 系统拆成了 Agent定义、模型、工具、编排、交接、护栏、人审、状态、可观测等模块，这说明真正的Agent已经是一个完整工程体系，而不是单点Prompt技巧。

二、Agent工程和传统后端系统有什么区别？

很多人做Agent工程时，最大误区是：把它当成普通后端接口来写。

传统后端系统是：

输入固定，逻辑固定，输出相对固定。

比如：

用户点击支付 → 校验订单 → 扣库存 → 调支付接口 → 返回结果。

这套流程是确定的。

但Agent系统不一样。

Agent面对的是自然语言目标，过程可能不固定。

同样一句“帮我整理一下客户问题”，它可能需要：

查知识库、查CRM、调用工单系统、总结历史对话、生成改进方案。

所以Agent工程有几个明显特点：

1、输入不稳定

用户表达很随意。

有人说：

“帮我看看这个客户咋回事。”

有人说：

“分析一下客户A最近为什么不续费。”

有人说：

“这个客户是不是要流失了？”

它们可能表达不同，但背后任务相似。

2、过程不稳定

Agent可能先查客户信息，也可能先查工单，也可能先查聊天记录。

这就要求工程系统必须能记录每一步。

3、结果需要评估

传统接口返回200不代表Agent做得好。

Agent返回了一段话，也不代表真的有用。

你要看：

有没有调用正确工具？
有没有查对数据？
有没有胡说？
有没有越权？
有没有生成可执行建议？

LangChain在Agent可观测文章里也强调，构建可靠Agent必须理解它的推理、工具调用和执行轨迹，不能只看最终返回结果。

三、Agent工程的整体架构应该怎么设计？

一个比较完整的Agent工程，可以拆成九层。

1、入口层：接收用户任务

入口可以是：

网页聊天框
企业微信/飞书/钉钉
APP对话框
后台运营系统
客服工作台
API接口

入口层要做三件事：

第一，接收用户输入。
第二，识别用户身份和权限。
第三，生成一次任务ID，方便后续追踪。

这里非常重要：每一次Agent执行，都必须有requestId、traceId、userId、sessionId。

否则线上出问题时，你根本不知道Agent为什么这么做。

2、意图识别层：判断用户到底想干什么

用户一句话进来后，不能直接丢给大模型乱跑。

要先判断意图。

比如：

用户是想查资料？
是想生成内容？
是想调用业务系统？
是想修改数据？
是想做分析？
还是只是闲聊？

意图识别可以用两种方式：

一种是规则+关键词。

比如包含“查询订单”“退款”“库存”，就进入对应流程。

另一种是轻量模型分类。

比如把用户问题分成：

知识问答类
数据查询类
内容生成类
流程办理类
工具执行类
复杂规划类

实际项目中，建议采用：

规则兜底 + 小模型分类 + 大模型二次判断

这样既快，又稳。

3、规划层：把大任务拆成小步骤

这是Agent最核心的部分。

用户给的是目标，Agent要把目标拆成执行计划。

比如用户说：

“帮我生成一份新品营销方案。”

Agent可以拆成：

1、确认新品信息。
2、查询目标用户画像。
3、查历史相似活动。
4、总结成功活动特点。
5、生成活动主题。
6、生成渠道策略。
7、生成预算建议。
8、输出完整方案。

这个过程叫规划。

但要注意，规划不能无限开放。

否则Agent会绕圈、乱查、乱调用工具。

所以工程上要设置：

最大执行步数
最大调用次数
最大Token预算
最大运行时间
失败重试次数
人工确认节点

Anthropic在构建有效Agent的文章中提到，成功的Agent实现通常不是依赖复杂框架，而是使用简单、可组合的模式。这个观点很关键：Agent工程不是越复杂越好，而是越可控越好。

4、工具层：让Agent真正能做事

没有工具的Agent，只是聊天机器人。

有了工具，Agent才能查数据、调用接口、发通知、生成文件、操作系统。

常见工具包括：

数据库查询工具
搜索工具
知识库检索工具
CRM查询工具
订单系统工具
工单系统工具
邮件发送工具
报表生成工具
代码执行工具
文件解析工具
日历工具
审批流工具

工具设计要注意一个原则：

工具要像“按钮”，不要像“黑盒”。

也就是说，每个工具要有清晰的功能边界。

例如：

不建议设计一个万能工具：

doAnythingTool(userInput)

而应该拆成：

queryOrder(orderId)
queryCustomer(customerId)
createRefundTicket(orderId, reason)
searchKnowledgeBase(keyword)
generateReport(data, template)

工具越清晰，Agent越不容易乱用。

Anthropic在工具设计文章中也提到，给Agent写工具时，需要重新思考传统软件开发方式，因为Agent面对的是非确定性调用场景。

5、记忆层：让Agent记住上下文和历史经验

Agent记忆一般分三类。

第一类是短期记忆。

也就是当前对话上下文。

比如用户前面说：

“我说的是华东区的数据。”

后面问：

“那这个月怎么样？”

Agent要知道“这个月”指华东区这个月。

第二类是长期记忆。

比如用户偏好、业务规则、历史操作习惯。

例如：

用户喜欢报告用表格。
某类审批必须走负责人确认。
某个客户属于重点客户。

第三类是任务记忆。

也就是Agent执行过程中产生的中间状态。

例如：

已经查过哪些数据。
调用了哪些工具。
哪些步骤失败了。
当前任务进行到哪里。

工程上可以这样设计：

短期记忆放在Session里。
长期记忆放在数据库或向量库里。
任务状态放在任务表、Redis或工作流引擎里。

但记忆不能无脑存。

要有写入规则。

比如：

用户明确表达的偏好可以存。
业务执行结果可以存。
敏感信息要脱敏。
临时信息不要长期保存。
错误结论不能直接进入长期记忆。

6、知识层：让Agent有可靠信息来源

很多Agent失败，不是模型不聪明，而是知识来源不可靠。

知识层通常包括：

企业文档
业务规则
产品手册
FAQ
历史案例
数据报表
接口文档
政策制度
用户画像
运营活动数据

知识层常见做法是RAG，也就是检索增强生成。

简单说：

用户提问后，不是让大模型凭空回答，而是先去知识库里查相关资料，再让大模型基于资料回答。

工程流程一般是：

文档采集
文档清洗
文档切片
向量化
入库
检索召回
重排序
上下文拼接
大模型生成
引用来源返回

这里要特别注意：

知识库不是“把文档扔进去”就完事。

真正难点在：

文档是否过期
切片是否合理
召回是否准确
权限是否隔离
答案是否引用依据
相似文档是否去重
表格、PDF、图片是否能处理

Agent不是替代知识库，而是把知识库变成可执行能力。

7、编排层：单Agent还是多Agent？

很多文章喜欢一上来讲多Agent。

但实际工程里，不建议一开始就搞复杂多Agent。

正确路线应该是：

先做单Agent。
单Agent稳定后，再拆专业Agent。
专业Agent多了，再做多Agent编排。

单Agent适合：

任务简单
流程短
工具少
风险低

多Agent适合：

任务复杂
角色分工明显
工具很多
需要专家协作

例如一个营销Agent系统，可以拆成：

意图识别Agent
活动分析Agent
用户画像Agent
文案生成Agent
合规检查Agent
投放建议Agent
复盘总结Agent

OpenAI Agents SDK中也提供了handoffs能力，用来让一个Agent把任务交给另一个专业Agent；也支持“agent as tool”，让主Agent调用专家Agent协助完成任务。

但多Agent有风险。

Agent越多，链路越长，越难调试。

所以要坚持一个原则：

能用流程解决的，不要急着用多Agent；能用工具解决的，不要急着让模型自由发挥。

8、护栏层：防止Agent乱来

Agent工程必须有护栏。

因为Agent不仅会说，还可能会执行动作。

如果没有护栏，它可能：

查了不该查的数据
调用了错误接口
生成违规内容
删除重要数据
越权审批
泄露敏感信息
把错误结果当事实

护栏可以分成几类。

第一，输入护栏。

检查用户请求是否合法。

比如：

是否包含敏感词
是否越权
是否试图绕过规则
是否要求执行危险操作

第二，工具护栏。

控制Agent能调用哪些工具。

比如：

普通用户只能查数据，不能修改数据。
删除操作必须人工确认。
转账、退款、发券必须二次确认。

第三，输出护栏。

检查最终回答是否合规。

比如：

是否包含隐私信息
是否包含不确定结论
是否编造数据
是否违反业务规则

第四，人工审核。

高风险任务必须人审。

例如：

批量发送营销短信
大额退款
删除客户数据
修改合同
对外发送正式邮件

OpenAI Agents SDK文档中也明确把guardrails和human review作为复杂Agent工作流的重要部分。

9、可观测层：把Agent每一步都记录下来

Agent上线后，最怕一句话：

“它刚才为什么这么回答？”

如果没有可观测，你只能猜。

所以Agent工程一定要有trace。

要记录：

用户输入
系统Prompt版本
模型名称
模型参数
检索关键词
召回文档
工具调用名称
工具入参
工具返回
中间状态
执行耗时
失败原因
最终输出
用户反馈

OpenAI Agents SDK内置Tracing，可以记录LLM生成、工具调用、handoff、guardrails和自定义事件，用于开发和生产环境调试。

Braintrust对Agent可观测的定义也很直接：要捕获Agent执行中的每一步，包括工具选择、工具参数、模型响应、记忆读写、状态变化和决策分支。

一句话：

没有Trace的Agent，不能上线。

四、Agent工程应该怎么一步步落地？

1、第一步：不要先做万能Agent，先选一个高频场景

很多团队一开始就想做：

“企业万能助手。”

这通常会失败。

因为万能助手边界太大，评测困难，权限复杂，用户期待也高。

更好的做法是：

先选一个明确场景。

比如：

客服工单分析Agent
营销活动生成Agent
合同审核Agent
数据查询Agent
会议纪要Agent
代码排查Agent
销售跟进Agent
知识库问答Agent

选择场景时，看四个指标：

是否高频
是否耗时
是否有明确输入输出
是否能衡量效果

比如“客服工单分析”就很适合。

输入：工单数据。
输出：问题分类、原因分析、处理建议。
效果：节省人工分析时间，提高问题定位效率。

2、第二步：定义Agent的职责边界

Agent不能什么都做。

要写清楚：

它能做什么
不能做什么
需要哪些工具
输出什么格式
什么时候需要人工确认
失败时怎么处理

例如：

客户分析Agent的职责：

能查询客户基础信息。
能查询历史订单。
能查询工单记录。
能总结风险点。
能生成跟进建议。

不能直接修改客户等级。
不能直接承诺退款。
不能查看无权限客户。
不能编造没有来源的数据。

这个边界越清楚，Agent越稳定。

3、第三步：设计工具，而不是只写Prompt

Agent效果好不好，很大程度取决于工具设计。

工具设计建议遵循五个原则。

第一，工具功能要单一。

一个工具只做一件事。

第二，参数要结构化。

不要让Agent传一大段自然语言。

第三，返回结果要干净。

不要返回一堆无关字段。

第四，错误信息要清楚。

比如：

“订单不存在”
“用户无权限”
“接口超时”
“参数缺失”

第五，高风险工具要加确认。

比如：

删除、发送、修改、支付、审批。

4、第四步：设计任务流程

Agent不是随便跑。

要有流程。

一个常见流程是：

用户输入
意图识别
权限校验
任务规划
工具调用
结果检查
继续执行
生成答案
输出校验
记录日志
用户反馈

复杂任务可以设计成工作流。

比如：

先检索资料
再分析数据
再生成报告
再合规检查
最后输出

流程要明确哪些步骤由模型做，哪些步骤由程序做。

一个重要原则：

确定性的事情交给代码，不确定的事情交给模型。

比如：

权限校验，用代码。
金额计算，用代码。
数据库查询，用代码。
语言理解，用模型。
方案生成，用模型。
复杂总结，用模型。

这样系统会更稳。

5、第五步：加入RAG，让回答有依据

如果Agent要回答业务问题，就必须有知识来源。

否则它很容易胡说。

RAG落地要关注五个点：

第一，文档清洗。

去掉页眉页脚、广告、重复内容、乱码。

第二，合理切片。

不能太长，也不能太碎。

第三，混合检索。

关键词检索适合精确词，向量检索适合理解语义。

第四，重排序。

把最相关的内容放到前面。

第五，答案引用。

告诉用户答案来自哪里。

比如：

“根据《售后规则》第3.2条……”

这能显著提升可信度。

6、第六步：加入记忆，但不要乱记

记忆是Agent体验升级的关键。

但记忆也很危险。

如果乱记，Agent会越来越偏。

建议设置记忆写入机制：

用户明确说“以后都这样”才写入长期偏好。
系统执行结果写入任务记忆。
业务规则由管理员维护，不由Agent随便修改。
敏感信息必须脱敏或不保存。
错误结果不能直接沉淀为知识。

记忆要能查看、能删除、能更新。

否则后面出了错，很难纠正。

7、第七步：做评测集，不要靠感觉判断效果

Agent上线前必须评测。

评测集可以分成几类：

简单任务
复杂任务
边界任务
异常任务
越权任务
工具失败任务
多轮对话任务
高风险任务

每条评测样本至少包含：

用户输入
期望意图
期望工具调用
期望输出要点
不能出现的内容
评分标准

评测指标可以包括：

意图识别准确率
工具调用准确率
任务完成率
答案正确率
引用准确率
平均耗时
平均成本
失败率
人工介入率
用户满意度

LangChain也提到，Agent评估不能只看最终答案，还要评估不同粒度的执行过程，生产trace可以成为持续优化的基础。

8、第八步：上线后持续优化

Agent不是上线即结束。

它更像一个需要持续训练和调优的系统。

上线后要看：

哪些问题经常失败
哪些工具经常调用错
哪些Prompt版本效果变差
哪些知识没有召回
哪些任务耗时过长
哪些回答用户不满意
哪些场景需要人工接管

优化方式包括：

补充知识库
调整Prompt
优化工具描述
增加参数校验
增加重试机制
增加人工确认
拆分复杂Agent
优化检索策略
降低模型成本

五、Agent工程中的核心模块怎么做？

1、Prompt怎么写？

Agent Prompt不能只写“你是一个聪明助手”。

要写清楚：

角色
目标
任务边界
工具使用规则
输出格式
禁止事项
失败处理
安全要求

例如：

你是一个客户分析Agent。
你的任务是根据客户资料、订单记录和工单记录，分析客户风险。
你只能基于工具返回的数据回答。
如果数据不足，要明确说明。
不能编造客户信息。
涉及退款、赔偿、合同修改时，必须提示人工确认。
输出包括：客户概况、风险点、原因分析、建议动作。

Prompt越像“岗位说明书”，Agent越稳定。

2、工具描述怎么写？

工具描述要让模型看得懂。

比如不要写：

getData：获取数据。

而要写：

queryCustomerOrders：根据customerId查询客户最近订单记录，适用于分析客户购买行为、消费频次、订单金额变化等场景。必须传入customerId，可选传入startDate和endDate。

好的工具描述包括：

工具用途
适用场景
必填参数
可选参数
返回内容
使用限制
失败处理

工具描述越清楚，Agent越不容易选错工具。

3、状态管理怎么做？

Agent执行过程一定要有状态。

状态包括：

当前任务目标
已完成步骤
待执行步骤
已调用工具
中间结果
错误信息
用户确认状态
最终输出

简单任务可以放在内存或Redis。

复杂任务建议放数据库或工作流引擎。

尤其是长任务，比如：

生成报告
批量分析
多系统审批
跨部门流程

必须支持：

暂停
恢复
重试
取消
回滚
人工介入

4、异常处理怎么做？

Agent工程里，异常是常态。

常见异常包括：

模型超时
工具超时
接口失败
参数错误
检索为空
权限不足
任务循环
输出不合规
用户输入不清楚

处理方式：

模型超时：自动重试或切换模型。
工具失败：返回明确错误，让Agent重新规划。
检索为空：提示缺少资料，不要胡编。
权限不足：直接拒绝，不进入后续流程。
任务循环：达到最大步数后停止。
输出不合规：重新生成或转人工。

5、成本控制怎么做？

Agent比普通聊天更贵。

因为它可能多次调用模型、多次检索、多次调用工具。

成本控制可以从几个方面做：

第一，模型分层。

简单分类用小模型。
复杂生成用大模型。
长文本总结用中模型。
高风险场景用强模型。

第二，缓存。

相同问题缓存答案。
相同知识检索缓存结果。
相同Prompt前缀使用前缀缓存。
相同工具查询结果短时间缓存。

第三，限制步数。

不要让Agent无限循环。

第四，压缩上下文。

不要把所有历史都塞给模型。

第五，工具优先。

能用接口查，就不要让模型猜。

六、Agent工程中最容易踩的坑

1、把Agent做成万能助手

万能助手看起来高级，实际上最难评估、最难上线。

建议先从垂直场景开始。

2、只调Prompt，不做工程

Prompt只能解决一部分问题。

真正稳定要靠：

工具设计
权限控制
状态管理
评测体系
日志追踪
异常兜底

3、不给Agent边界

没有边界的Agent很容易乱查、乱答、乱调用。

4、工具太粗

一个万能工具会让Agent误用。

工具要小而清晰。

5、没有Trace

没有Trace，就无法复盘。

出了问题只能猜。

6、没有评测集

靠人工感觉调Agent，很快会失控。

7、没有人工确认

涉及高风险操作，必须人审。

8、让模型做确定性计算

金额、库存、权限、订单状态这些要用代码，不要让模型算。

七、一个可落地的Agent工程案例：营销活动Agent

假设要做一个营销活动Agent。

用户输入：

“帮我给618活动生成一个老用户召回方案。”

系统流程可以这样设计：

1、意图识别

识别为：

营销方案生成
用户召回
活动策划

2、权限校验

判断用户是否有查看活动数据、用户画像和历史活动数据的权限。

3、任务规划

拆成：

查询历史召回活动
查询老用户画像
分析流失原因
生成活动主题
生成优惠策略
生成触达渠道
生成文案
生成风险提示
输出完整方案

4、工具调用

调用：

历史活动检索工具
用户画像查询工具
活动效果分析工具
文案生成工具
合规检查工具

5、生成方案

输出：

活动目标
目标人群
活动主题
权益设计
渠道策略
触达节奏
文案示例
预期指标
风险控制
复盘指标

6、合规检查

检查是否包含：

夸大宣传
违规承诺
敏感词
不合理优惠
用户隐私信息

7、最终输出

给用户一份可执行方案。

8、记录Trace

记录：

输入是什么
调用了哪些工具
查到了哪些活动
用了哪个Prompt版本
生成结果是什么
合规检查结果是什么

这样才叫完整Agent工程。

八、Agent工程的技术选型建议

1、模型层

可以采用多模型策略：

大模型负责复杂规划和生成。
中模型负责总结和改写。
小模型负责分类、路由、简单判断。

不要所有任务都用最贵的大模型。

2、检索层

可以用：

Elasticsearch
Milvus
pgvector
Weaviate
Qdrant
向量数据库 + 关键词检索

如果业务已有ES，也可以做混合检索。

ES适合关键词、过滤、排序、权限字段。

向量库适合语义召回。

两者结合效果更好。

3、编排层

可以用：

LangGraph
OpenAI Agents SDK
LlamaIndex Workflows
自研工作流
Temporal
Airflow类任务系统

如果场景简单，自研也可以。

如果多Agent复杂，建议使用图式编排或工作流引擎。

4、可观测层

至少要支持：

日志
Trace
指标
告警
评测结果
用户反馈

可以接入：

OpenTelemetry
LangSmith
Braintrust
自研日志平台
Grafana
Prometheus

Agent可观测现在已经成为生产Agent的关键能力，LangChain的“State of Agent Engineering”中也提到，多步骤推理链路和工具调用追踪已经成为Agent系统的基础能力。

九、Agent工程上线标准

一个Agent能不能上线，可以看这张清单：

1、是否有明确业务场景？
2、是否有清晰职责边界？
3、是否有权限控制？
4、是否有工具调用规范？
5、是否有最大执行步数？
6、是否有失败重试？
7、是否有人工确认？
8、是否有日志和Trace？
9、是否有评测集？
10、是否有灰度机制？
11、是否有回滚方案？
12、是否有成本监控？
13、是否有安全护栏？
14、是否有用户反馈入口？

满足这些，才算从Demo走向工程化。