Agent应用落地避坑指南：技术经验全公开-优快云博客

一、概述

2025年被称为Agent元年，很多与Agent相关的应用、框架和协议在如火如荼的迭代升级。但我的感受是，市面上很多ToC的Agent应用看起来效果很惊艳，但真正落地ToB场景产生商业价值，能给企业带来实际收益的确寥寥无几。除开企业价值等因素，单从技术层面，以个人薄见主要原因有两点：

ToB客户真实的需求场景往往很复杂，需要深入挖掘了解业务才知道数据构建和技术应该朝什么方向演进；
当前Agent还处于探索阶段，企业客户最关心的“稳定性”难以保证。

总的来说，**客户需要的并不是某个单点技术能力，而是一整套解决方案以保障效果和效率。**下面分享下个人在实际项目做Agent应用过程中遇到的问题，以及对现有Agent框架做了哪些优化。

二、技术现状

目前Agent主流的决策框架主要有ReAct和Plan-and-Execute ReAct两种：

1）标准ReAct：原理很简单，就是用户问题进来后，经过Thought（思考）->Action（返回待执行工具列表）->Observation（工具执行结果）-> Thought（思考下一步要做什么）->…-> Answer（总结回复）这么一套链路。新手需注意大模型不会直接执行工具，需要调用工具时只是返回Action，里面记录工具名称和入参，由额外的编译器解析执行。

在这里插入图片描述

图1-标准ReAct执行流程

这里提到的MCP是大模型与外部资源通信的协议，具体内容可自行查阅，不在这里展开叙述。实际应用中对于单Agent的简单场景，插件数量也很少，可以不需要通过[MCP协议]，直接手动补全写个prompt就行。

标准ReAct的prompt模版如下：

Respond to the human as helpfully and accurately as possible.

{{instruction}}

You have access to the following tools:

{{tools}}

Use a json blob to specify a tool by providing an {{TOOL_NAME_KEY}} key (tool name) and an {{ACTION_INPUT_KEY}} key (tool input).
Valid "{{TOOL_NAME_KEY}}" values: "Final Answer" or {{tool_names}}

Provide only ONE action per $JSON_BLOB, as shown:

```
{
"{{TOOL_NAME_KEY}}": $TOOL_NAME,
"{{ACTION_INPUT_KEY}}": $ACTION_INPUT
}
```

Follow this format:

Question: input question to answer
Thought: consider previous and subsequent steps
Action:
```
$JSON_BLOB
```
Observation: action result
... (repeat Thought/Action/Observation N times)
Thought: I know what to respond
Action:
```
{
"{{TOOL_NAME_KEY}}": "Final Answer",
"{{ACTION_INPUT_KEY}}": "Final response to human"
}
```

Begin! Reminder to ALWAYS respond with a valid json blob of a single action. Use tools if necessary. Respond directly if appropriate. Format is Action:```$JSON_BLOB```then Observation:.
Question:{{input}}

------补充说明------
{{instruction}}：任务说明，描述清楚你需要让模型解决什么问题，具体的工作流程和注意事项等
{{tools}}：工具列表
{{input}}：用户输入的问题

------执行过程------
第一次调用大模型的输入（放入user role中）：
{{prompt}}
Question:{{input}}
返回：
Thought:...
Action:...
第一次调用工具解析执行器
返回：
Observation:...

第二次调用大模型的输入（放入user role中）：
{{prompt}}
Question:{{input}}
Thought:...
Action:...
Observation:...
返回：
Thought:...
Action:...
第二次调用工具解析执行器
返回：
Observation:...

...循环Thought/Action/Observation

判断可以给用户总结回复：
返回：
Thought:...
Action:
```
{
"{{TOOL_NAME_KEY}}": "Final Answer",
"{{ACTION_INPUT_KEY}}": "..."
}
```

2）Plan-and-Execute ReAct

标准ReAct更像是“深度搜索”，**边规划边执行。**而该方案类似“广度搜索”，先规划后执行，使用“1+N”多智能体协作的方式，先由“1”智能体给出执行计划，在协调“N”方向智能体按计划的步骤执行；当计划执行完毕后，需要反馈给“1”判断是否需要给出新的执行计划，如果不需要则给用户总结回复。
“1”和“N”方向Agent的分工：“1”主要负责plan、异常处理、总结；“N”负责具体的执行，包括工具调用、异常上报、问答。

在这里插入图片描述

图2-Plan-and-Execute ReAct执行流程

基于该方案还有进一步的衍生方案，比如LLMCompiler，规划时生成一个DAG图来执行Action，可以理解成将多个工具聚合成一个工具执行图，用拓扑图的方式执行任务。该方式可以并行执行多个无依赖关系的工具，减少大模型调用次数以提高响应效率。

图3-LLMCompiler执行流程

现在市面上主流的Agent框架，如[langgraph]和[CrewAI]等，不过是对这2种决策模型的工程化实现，不再一一介绍。

在这里插入图片描述

三、项目落地过程中遇到的问题

1.ReAct框架目前的局限性

（1）标准ReAct

标准ReAct框架简单易用，非常适用于业务逻辑不复杂，单Agent少量工具的简单场景。但问题也比较明显：

a. 最终的回复放在Action的Json中，工程化时需要完整的把Json解析完才能给用户展示；如果最终回复比较长，且回复中可能还会包含其他业务需要大模型总结的结构化信息，会导致用户等待时间较长，感知不好。

b. 每次只能规划调用1个工具，当工具较多时会导致大模型调用次数增多，响应时间太长；但实际业务中有些工具之间没有依赖关系，可以并行调用。

c. 稳定性问题，尤其有特定需求需要对标准的prompt框架做改动调整时更明显，模型经常丢失如“Action:/Thought:”这样的前缀，或者最终回复的前面没有经过Thought直接输出。

（2）Plan-and-Execute ReAct

这个框架看起来很美好，先Plan再执行，也支持并行调用多个工具。但实际使用中，模型很难做完整正确的Plan，经常出现的是Plan的多个步骤之间有重复或存在缺失，即使每次执行完后会重新反思Replan，但重新Plan的步骤可能还会出现和上次规划重复或输出与之前有矛盾的步骤，需要靠prompt工程和复杂的异常处理机制来兜底，且每次更换或更新模型，相同的prompt就不能很好的work了，调prompt就让人心力交瘁。

2.业务需求的复杂性

在讲述业务需求之前，需要先讨论个概念，即什么是Agent？客户、产品和技术侧对这个概念的理解存在差异：

1）客户：是一套智能体应用，内部实现不一定是采用大模型任务规划。客户关注的是最终产品的展示形态，如知识问答类AI客服和业务办理类AI客服，客户认为是2个Agent，但内部可能就是RAG/DeepSearch问答或通过[workflow画布流程]配置实现。

2）产品：是一个智能体平台，支持2种配置模式：workflow画布流程（静态任务规划）；另一种是agentic的方式（无画布流程的动态任务规划）

3）算法：我们理解的Agent主体是以纯大模型的动态任务规划为主，包括多智能体协同，以及如何与产品更好的结合。

结合刚刚讨论的内容，实际做项目过程中，客户的业务场景主体分为3大类：

1）纯问答类：针对客户提供的私域知识文档给用户直接回复。这类业务大多不涉及多轮交互，以一问一答为主；有的客户在部分场景允许接入联网知识，集外知识要区分拒识和闲聊等。

2）workflow类：我们通常称之为“静态任务规划”，以查办类业务为主。这类业务通常有标准的业务流程，如车险报案，需要逐步让客户提供信息（姓名、车辆信息、出险地点等，通过在画布中配置连续的提槽节点实现），最后形成报案工单，步骤明确。模型只需关注意图识别、槽值抽取和话术生成（引导、跳转拉回等）3类原子能力，其他的如整体的流程控制、工具调用等都可以通过画布拖拽节点实现。出于业务性质和稳定性的考虑，实际项目交付过程中大多数业务流程都是通过在产品配置workflow实现。

3）agent类：这里特指需要“动态任务规划”类的业务。适用于无固定交互流程且需要查询外部信息进行规划推理的场景（如理财产品推荐/设备故障排障，需要分析用户问题才知道需不需要调用工具进行任务编排，判断后续的执行动作应该是什么，无法通过画布配置固定流程实现）。

真实项目中大多以纯问答和workflow类实现的业务为主，尤其涉及到业务安全性和实时性高的场景，通过纯agent任务规划实现基本不可行（尤其在金融领域，大模型监管备案异常严格，客户对新技术的需求也相对保守）。只有些比较开明，对前沿技术有追求的客户会分小部分安全性和实时性要求不高的场景允许我们做纯agent的尝试和研究，并集成到产品中，当用户问题通过意图分流到这些场景中时可以进行交互体验。

对于涉及到需使用Agent的场景，往往不单是调用接口工具那么简单。在Agent规划的过程中，还需要跟用户做多轮交互以确认工具查询不到的信息；然后某些规划步骤的执行可能需要调用另一个Agent才能完成。举个做过的燃气公司的故障排障场景（简化说明），用户只说“燃气无法使用怎么办”，那么Agent需要先查询接口工具获取用户房产信息，通过房产信息查询系统中有没有停气、设备故障等信息；如果系统接口查不到问题，则需要跟用户交互，通过提槽方式确认家中的设备可用状态，若用户表示均不可用，则按照报警器—>燃气表—>阀门—>燃气设备的顺序进行指引排障（具体每类的排障过程会对应4个子Agent，因为内部也有比较复杂的流程），并基于用户的反馈调整排障策略。该场景就涉及到多智能体的协作。

综合来说，除了Agent技术本身，在项目落地过程中更需要设计一套完整的技术解决方案，在让客户能够感受到Agent赋能的同时解决客户实际相对全面的业务需求。

四、优化方案

针对上述问题，在做具体项目过程中，我结合项目需求做了很多技术和工程化相关的优化设计，大体内容如图所示：

在这里插入图片描述

图4-交互问答技术全景概览图（个人原创，禁止盗用）

内容有点多，关于纯问答相关的技术（如联网搜索问答、DeepSearch）暂不展开阐述（后面有时间更新），本次主体还是聚焦在Agent任务规划的优化说明。

注：因公司规定，优化后的完整prompt和我写的代码不便提供，但至少我可以把遇到的问题和优化思路分享给大家，希望对各位有所启发。

4.1 ReAct框架升级

主体还是基于标准ReAct的框架（“规划一步执行一步”的方式）进行升级，支持了Multi-Agent的模式。没有采用先Plan后执行的方式，因为实测Plan的不稳定性很高，异常处理模块比较难兜底。主要的优化点如下：

1.快慢思考模型结合，“规划”和“总结回复”配置不同模型执行

慢思考模型（思考+回复）出来之前，基本规划和总结回复都是通过1个快思考模型做。但是实际使用发现最后的总结回复涉及到对工具调用结果的整理、分析和思考推理，快思考模型的效果并不好。在慢思考模型出来后，我们尝试将这两部分拆开，规划用快思考模型（例如[deepseek V3]，最后的回复总结用慢思考模型（如[deepseek R1]），最终的回复效果会比只用1个模型好很多。

具体实现上，可以通过工程化解析快思考模型是否输出最终回复的前缀标签（可配，如“Finish:”等），如果解析到了就中断模型的输出，清除这轮模型的回复，转而调用慢思考模型去做回复总结。

2.“泛化”工具的定义和使用方式

目前研究者对工具的定义大多是作为函数接口或服务使用（服务本质上也可以理解为1个大“函数”，给输入返回输出）。但前面提到在真实场景中，Agent在做任务规划时，不光是需要通过函数接口工具获取信息，同时也需要与用户交互获取信息以决策下一步需要做的事情，或者将某个步骤的执行下发给其他Agent，获取其他Agent的返回结果后再决策下一步需要做什么。

综上，我充分利用Action定义的Json结构，将工具定义为3种类型：

（1）函数类工具：传统的接口或服务，用于获取工具的执行结果（也可以获取问答知识）。模型输出对应的接口名称和入参，编译器解析执行后返回运行结果。大模型输出的格式：Action:[{“tool_name”:“ $KaTeX parse error: Expected '}', got 'EOF' at end of input: \dots名称}","input":{"$ {入参}”:“…”,…}}]。用列表的格式是允许Action一次可传入多个没有依赖关系的工具。

（2）交互类工具：当Agent规划当前需要从用户那里获取信息时返回，格式如下：Action:[{“tool_name”:“ask_user”,“input”:{“query”:“…”}}]。这里的tool_name“ask_user”只需设置为1个固定字符串用于解析就行，不一定要用这个；入参就是需要咨询用户的问题，等待并获取用户响应后，将用户输入放入Observation中作为“ask_user”的“output”即可。

（3）Agent类工具：当Agent判断某个信息需要其他Agent反馈时使用，格式如下：Action:[{“tool_name”:“${Agent名称}”,“input”:{“query”:“…”,…}}]。这里的tool_name就是需要调用的Agent名称，input中放入需要其他Agent解决的问题，同时也可以传入一些背景信息。最后将其他Agent最终的总结回复放入当前Agent本次的Observation中。

4.2 Multi-Agent规划执行示例

拿燃气故障排障场景给大家一个执行的例子（为便于展示对具体输出内容进行了删减，大家以理解格式和执行过程为主）：

注：“//”后的内容为我写的注释，不是模型生成的内容

Question:我家燃气无法使用了怎么办？
Thought:...根据业务流程说明，需要首先询问用户是否为工商户，如果不是工商户才进一步按排障流程执行...
Action:[{"tool_name": "ask_user", "input": {"query": "您好，请问您是否为工商户？"}}]
//等待用户输入
Observation:[{"tool_name": "ask_user", "output": {"user_response": "不是"}}]
Thought:...判断用户不是工商户，需要根据用户手机号查询用户的房产信息... //这里手机号是作为外部信息提前传入prompt中的
Action:[{"tool_name": "...", "input": {"user_phone_number": "..."}}]
//等待编译器执行
Observation:[{"tool_name": "...", "output": {"address":"...",...}}]
Thought:...根据房产信息中的...字段，查询燃气及设备故障信息...
Action:[{"tool_name": "...", "input": {...}}]
//等待编译器执行
Observation:[{"tool_name": "...", "output": {...}}]
Thought:...未查询到用户存在停气或设备故障信息，需要跟用户确认是否所有燃气设备都无法使用，若不是需指出具体哪个设备不可用...
//这块有个业务逻辑，就是用户家的表不一定是智能表，或即使是智能表，故障信息也不是实时更新，所以系统里没有查到异常不代表真的没有，只能跟用户交互去排障
Action:[{"tool_name": "ask_user", "input": {"query": "...请问您家中的燃气设备是否全部都无法使用？"}}]
//等待用户输入
Observation:[{"tool_name": "ask_user", "output": {"user_response": "是的"}}]
Thought:用户表示燃气设备全都无法使用，接下来需要依次进行报警器排障、燃气表排障、阀门排障、燃气设备排障。
Action:[{"tool_name": "x_agent", "input": {"query": "用户家中燃气设备全部无法使用，需排查报警器是否有故障"}}]
//---调度报警器排障Agent---
Thought:...
Action:...
Observation:...
Thought:...
Finish:经过排查，用户的报警器无异常...
//---调度结束，返回主Agent
Observation:[{"tool_name": "x_agent", "output": {"agent_response": "经过排查，用户的报警器无异常..."}}]
Thought:接下来需要进行燃气表排障...
Action:[{"tool_name": "y_agent", "input": {"query": "用户家中燃气设备全部无法使用，需排查燃气表是否有故障"}}]
//---调度燃气表排障Agent---
Thought:...
Action:...
Observation:...
Thought:...
Finish:经过排查，用户的燃气表存在...异常，需要告知用户执行...操作，并询问用户燃气表是否恢复正常
//---调度结束，返回主Agent
Observation:[{"tool_name": "y_agent", "output": {"agent_response": "经过排查，用户的燃气表存在...异常，需要告知用户执行...操作，并询问用户燃气表是否恢复正常"}}]
Thought:当前发现燃气表出现...异常，需要告知用户执行...操作，并询问用户燃气表是否恢复正常
Action:[{"tool_name": "ask_user", "input": {"query": "当前发现燃气表出现...异常，请您按执行...操作，看燃气表是否恢复正常了呢？"}}]
...
//依次完成对报警器排障、燃气表排障、阀门排障、燃气设备的排障后，需询问用户的问题是否已解决
Thought:当前已完成对报警器排障、燃气表排障、阀门排障、燃气设备的排障，用户反馈所有燃气设备已恢复正常，需询问用户的问题是否已解决
Action:[{"tool_name": "ask_user", "input": {"query": "当前燃气设备均已恢复正常，请问您的问题是否已解决呢？"}}]
//等待用户输入
Observation:[{"tool_name": "ask_user", "output": {"user_response": "是的，燃气可以用了，感谢"}}]
Thought:所有任务已执行完毕，用户反馈问题已解决...
//最终回复中需要总结当前排查过程中出现了哪些问题，以及如何解决的；这个信息主要是燃气公司要将本次排查过程记录成工单所需，<final_json>...</final_json>中的内容可以不给用户展示
Finish:好的，有其他问题欢迎咨询！<final_json>{"summary": "经过排查..."}</final_json>

4.3 异常处理

不好讲的太细，大体说一些常见的：

1）模型有时会出现“臆想”工具执行结果的情况：当模型输出“Observation…”时，需要工程化截断并删掉包含“Observation…”及其后的内容；

2）正则过滤经常出现的错误模式：比如结构化数据前后多余的换行空格；

3）对于函数类工具，若模型生成的工具名称或入参出现错误导致解析器调用失败，需工程化捕获异常，重新请求大模型生成Action；如果超过一定次数均失败，这时的兜底处理就取决于产品经理和客户的想法了，这块要以客户能接受的方式为主（像燃气这边的客户打趣说直接像deepseek刚发布时一样告诉用户“系统繁忙请稍后重试”也是可以的，总之不能告诉用户是模型错了哈哈）

4）对于交互类工具，如果格式解析有异常，因为就是跟用户交互，只要能根据关键词（比如示例中的“ask_user”）判断出是这类工具，直接代码重新拼个，清空历史保存的错误Action就行

5）对于Agent类工具，如果子Agent执行中出现异常，捕获后也是需要尝试重新调用，处理方式与3）类似

6）需要做重复规划或循环规划的检测：分析最新规划的Action结果是否在历史记录中出现过，若存在重复规划需要在下次调用大模型时输入冲突提示并重新请求规划，如果“无效”规划超过一定次数也是要有兜底策略，如参考3）的处理策略或其他方式，需要与产品经理和客户沟通。

4.4 其他技术点探讨

前面提到，真实场景中，往往Workflow（固定流程的查办类业务）、纯Agent（无固定流程的复杂业务）和纯问答（咨询）场景都会有，那会产生以下几个问题：

1）“多意图”问题

用户问题进来首先会进行意图识别，若用户一句话同时包含多个意图（如Workflow、Agent和问答类场景的排列组合），应该怎么处理？或者用户表述不清，应该怎么做？

分析这个问题不能一上来陷入细节，先从大体框架说起：

图5-不同识别意图情况下的处理逻辑

注：因为我这边主要是做客服场景为主，虽然多意图的处理比较复杂，在实际交付项目中，多意图在客户生产环境占比本身就不高，因为大多用户一般不会一句话提出多个请求；模糊的问题相对占比高一点，因为有些用户就是讲不清楚需求，但这种的处理方式相对简单，就是基于识别到的模糊候选意图多问一次（关于多意图/模糊意图的识别技术方案暂不展开，这个没大家想的那么简单，几句话说不完）。下面单纯从技术实现的角度，探讨下多意图的处理方式：

广义的“多意图”也包含“意图+问答”的情况，需要分情况讨论（为了表示方便，我把workflow类的意图用“W”表示，Agent用“A”，问答用“Q”）：

a. W+Q/A+Q：这是实际业务中涉及多意图最多的情况，一种处理方式就是“问答回复+流程首句引导语”，但实际项目中通常会采用“W/A优先”的方式，即忽略问答部分，先帮用户处理业务需求，技术实现上也更简单一些，客户通常也能接受。

b. W+W：参考图5，通常是按识别到的多业务意图顺序执行，未执行的先入栈（我们默认栈的大小是2，即最多缓存2个意图），若栈满则“淘汰”早期的意图。但这块也没那么简单，真要做深，实际是要考虑图中标黄的“意图筛选排序”的策略，即需要考虑意图之间的关联关系（如语义顺序，业务优先级，互斥关系等）。“业务优先级”是指用户提到的多个意图，在真实业务中某个意图流程必须先于另一个意图办理，这里可能是2个意图存在依赖关系，或者就是业务上通常会先走某个意图流程。举个例子，在保险报案场景，如果用户说“查查理赔进度，我出车祸了要报案”，业务上通常都是先处理报案，再查用户是不是之前有其他理赔的情况要查询，此时就不能依据用户表达的语义顺序执行多意图。“互斥关系”是2个意图在业务上不能同时执行，需要筛选掉其中1个。篇幅关系不展开叙述，总之想做好这个是需要深度打磨业务才行的。

c. W+A：这个处理方式很难有统一的方式，因为不同领域的客户基于他们的业务属性，对这个问题的看法是不一样的。可以采用“W+W”的处理方式，实际有的客户也会采用“W优先”舍弃A，客户也能接受，而且用户真想用A可以多问一次（毕竟A是不稳定的，能让用户少用就少用）。

d. A+A：参考“W+W”或“W+A”的方式都有人能接受，实际可与客户沟通看那种方式更贴合业务。

2）“意图跳转”问题

若用户在Workflow/Agent的交互流程中未执行完，跳转到其他Workflow、Agent或问答场景怎么办？

这里还是分情况讨论：

a. W->Q：一般是在提槽阶段，客服请求用户提供某个信息，结果用户打个岔问个问题，这种可以单独设计个prompt做“提槽引导语生成”，先给问答回复，在末尾拼接提槽引导语拉回主流程。

b. A->Q：这种一般发生在Agent需要使用“交互类工具”时出现，用户没有直接提供Agent需要的信息而是问了其他咨询的问题，这时需要暂存Agent的环境，在通过知识问答的链路给出回复后，Agent需要获取问答的回复，并自行思考拉回策略，可以在最初的Agent prompt中加入这种情况下的需求描述。

c. W/A->W/A：发生业务意图跳转时，当前意图需要缓存到意图栈中；若意图栈已满，则需删去栈底流程意图后当前意图再入栈，即抛弃早期的业务流程；这里也可以配合产品的工程化实现，即不同业务可以通过配置由运营决定当前意图流程是否允许跳转到其他意图，或跳转后是否需要拉回，这样会更灵活。

3）上下文管理问题

有多轮交互时，若同时涉及到上面提到的3类场景，一般不建议全局共享上下文，最好是Workflow、Agent和知识问答各自维护独立的上下文，因为这3类场景的上下文如果杂糅在一起，对彼此都会出现很多无关的信息，干扰模型的理解和推理。