企业官网建设流程全解析

1. 从"看得见"与"看不见"说起：Agent重构的真实图景

"Agent重构一切"这句话，最近半年在技术圈里被反复提起。有人把它当成新一轮技术叙事的口号，有人已经在生产环境里跑了大半年，还有人持观望态度，觉得又是一波概念泡沫。我属于第二类——从去年下半年开始，我陆续把几个内部工具链和业务模块改造成了Agent驱动的形态，踩了不少坑，也尝到了甜头。

先说结论：Agent确实在重构很多东西，但重构的方式和大多数人想象的不一样。看得见的波涛汹涌，是各种Demo、框架、产品层出不穷，每天都有新东西冒出来；看不见的河床变迁，是底层的工作流组织方式、人机协作边界、甚至团队的分工结构，都在悄悄发生位移。前者热闹，后者才是真正决定成败的地方。

这篇文章不打算复述任何框架的官方文档，也不打算做概念科普。我想做的是把"Agent重构"这件事拆开，从设计思路、核心细节、实操过程到问题排查，完整地讲一遍我自己的理解和实践。适合已经在做或者准备做Agent相关项目的开发者、产品经理和技术负责人参考。如果你还在纠结"要不要入场"，看完应该能有个判断；如果你已经在做了，希望里面的踩坑记录能帮你少走点弯路。

2. 内容整体设计与思路拆解

2.1 为什么是"重构"而不是"叠加"

很多人对Agent的理解是"给现有系统加一个智能层"——原来有个流程，现在在某个环节塞一个LLM调用进去，让它帮忙做点判断或者生成点内容。这种思路不能说错，但它只是"叠加"，不是"重构"。

叠加和重构的区别，我用一个具体场景来说明。假设你有一个客服工单系统，原来的流程是：用户提交工单 → 分类打标 → 分配给对应客服 → 客服处理 → 归档。叠加的做法是在"分类打标"这一步用LLM替代原来的规则引擎，准确率可能从70%提到85%，但整个流程的结构没变。

重构的做法是：把整个工单处理看成一个目标，让Agent自己去决定要不要分类、要不要分配、要不要直接回复、要不要升级。分类不再是流程里的一个固定节点，而是Agent在需要的时候才会调用的一个工具。流程从"固定管道"变成了"目标驱动的动态编排"。

这个区别为什么重要？因为固定管道的瓶颈往往不在单个节点的准确率，而在管道本身的结构刚性。用户的问题变了、业务规则变了、渠道变了，管道就得重新设计。而Agent驱动的动态编排，理论上可以自适应这些变化——当然，"理论上"和"实际上"之间隔着大量的工程工作，这个后面会详细讲。

我选择重构而不是叠加，核心原因是：叠加的收益有上限，重构的收益虽然不确定但天花板高得多。叠加最多把某个环节的效率提升20%-30%，重构有可能把整个流程的人力投入砍掉一半以上。当然，风险也大得多，所以需要一套方法论来控制。

2.2 重构的三个层次：交互层、编排层、执行层

我把Agent重构分成三个层次来考虑，这个分层方式是我自己在实践中总结的，不一定通用，但对我很有用。

交互层是最容易被看到的。用户直接接触的部分，从原来的表单、按钮、菜单，变成了对话、自然语言指令、甚至语音。这一层的变化最直观，也最容易做Demo，但它的价值其实是最浅的——如果底下的编排和执行没变，交互层换个皮，用户体验的提升有限。

编排层是核心。原来由人或者硬编码的流程引擎决定"下一步做什么"，现在由Agent根据当前状态和目标来决定。这一层的变化是看不见的，但影响最大。编排层的重构涉及到：任务如何分解、工具如何选择、状态如何管理、异常如何恢复、多轮对话的上下文如何维护。这些问题的复杂度远高于交互层。

执行层是工具和数据。Agent要做事，得有能力调用外部系统——查数据库、发邮件、调API、操作文件。这一层的变化相对小，主要是把原来给人用的接口改造成给Agent用的接口，但"给Agent用"和"给人用"的要求很不一样，后面会专门讲。

我自己的项目里，交互层的改造大概花了20%的精力，编排层花了60%，执行层花了20%。但收益的分布正好反过来——编排层的重构贡献了大部分的实际价值。所以如果你准备做Agent重构，我的建议是：不要在交互层上过度投入，把主要精力放在编排层。

2.3 方案选型的几个关键决策

具体到技术方案，有几个决策点是我踩过坑之后才想清楚的。

第一个决策：用现成的Agent框架还是自己搭。现成框架的好处是上手快，坏处是抽象层次往往和你的业务不匹配，改起来比自己写还麻烦。我的选择是：早期用框架快速验证，验证通过后逐步替换成自己写的编排逻辑。框架只用来做原型，生产环境用自己的代码。这个策略的好处是既享受了快速验证的红利，又避免了被框架绑架。

第二个决策：单Agent还是多Agent。多Agent听起来很美好——每个Agent负责一个领域，互相协作。但实际做下来，多Agent的通信开销、状态同步、错误传播问题非常棘手。我的经验是：除非任务天然可以分解成独立的子任务，否则优先用单Agent加多工具。多Agent不是不能用，而是它的复杂度增长不是线性的，是超线性的。

第三个决策：工具的数量和粒度。工具太少，Agent能力不足；工具太多，Agent选择困难，而且容易选错。我试过给一个Agent配30多个工具，结果它在选择工具上的错误率明显上升。后来精简到12个左右，准确率反而提高了。工具的设计原则是：每个工具解决一类明确的问题，工具之间的边界清晰，不要有功能重叠。

第四个决策：要不要做微调。我的结论是：绝大多数场景不需要微调，提示词工程加上好的工具设计就能解决80%的问题。微调适合的是那些有大量标注数据、任务非常固定、对延迟和成本极度敏感的场景。盲目微调是浪费时间和算力。

3. 核心细节解析与实操要点

3.1 任务分解：Agent重构的第一道坎

Agent要完成一个复杂任务，第一步是把它分解成可执行的子任务。这一步做不好，后面全白搭。

我遇到的最典型的问题是：分解得太粗，Agent执行到一半发现信息不够，又得回头问用户；分解得太细，Agent陷入细节，忘了整体目标。这个度怎么把握？

我的做法是：分解的粒度以"一次工具调用能完成"为标准。比如"帮我把这份报告发给团队"，分解成：确认收件人列表 → 生成报告摘要 → 调用邮件工具发送。每一步都是一次明确的工具调用，不需要中间再做判断。如果某一步需要判断，就再往下拆一层。

但这里有个陷阱：不是所有任务都能提前分解好。有些任务需要根据中间结果动态决定下一步。这时候就需要"动态分解"——Agent先执行一步，看结果，再决定下一步。动态分解的难点在于状态管理：Agent需要记住已经做了什么、当前在哪个子任务、还有哪些没做。我的做法是用一个显式的任务栈来管理，而不是完全依赖上下文窗口。

注意：任务栈要持久化。我早期用内存里的变量存任务栈，结果服务重启后Agent就"失忆"了，用户得重新说一遍需求。后来改成存数据库，虽然多了一次读写，但可靠性提升明显。

3.2 工具设计：给Agent用的接口和给人用的不一样

这是我最想强调的一点。很多人把现有的API直接暴露给Agent，然后抱怨Agent用不好。问题不在Agent，在接口设计。

给人用的接口，可以假设调用者理解上下文、知道参数含义、能处理异常。给Agent用的接口，这些假设都不成立。Agent看到的只是工具的名称、描述和参数schema，它不知道这个工具在什么场景下用、参数填错了会怎样、返回的错误码是什么意思。

所以给Agent用的工具，需要额外做几件事：

• 描述要写清楚使用场景，不只是功能。比如"查询订单状态"这个工具，描述里要写"当用户询问订单进度、物流信息、预计到达时间时使用"，而不是只写"查询订单"。
• 参数要有默认值和约束。Agent经常漏填参数或者填错类型，有默认值能兜底，有约束能在调用前就拦住错误。
• 返回值要结构化且自解释。不要返回一个裸的JSON，要返回带字段说明的结构。Agent看不懂{"code": 200, "data": {...}}里的data是什么，你得告诉它。
• 错误信息要可操作。不要返回"参数错误"，要返回"参数order_id格式不对，应该是12位数字字符串，你传的是8位"。Agent看到后者才知道怎么改。

我做过一个对比测试：同一批任务，用改造前的工具，Agent成功率62%；用改造后的工具，成功率89%。工具设计的重要性可见一斑。

3.3 上下文管理：Agent的"记忆"怎么管

Agent的上下文窗口是有限的，但任务可能需要很长的历史。怎么在有限窗口里塞进最有用的信息，是个核心问题。

我的策略是分层管理：

关键是任务层。我见过很多实现把任务状态混在对话历史里，结果对话一长，任务状态就被淹没了。正确的做法是把任务状态单独拎出来，用结构化的方式表达，每轮都重新注入。这样不管对话多长，Agent始终清楚自己在干什么。

历史层的摘要也有讲究。不要用LLM随便摘要，要按"对当前任务是否有用"来摘要。比如用户之前提到过"我下周要出差"，如果当前任务是订机票，这条信息就很重要；如果当前任务是写代码，就不重要。摘要的时候要带上这个判断。

3.4 异常处理：Agent出错之后怎么办

Agent一定会出错。工具调用失败、参数填错、理解偏差、陷入循环——这些都是常态。关键是怎么处理。

我的原则是：能自动恢复的自动恢复，不能自动恢复的优雅降级，实在不行的明确报错。

自动恢复的典型场景：工具调用超时，重试一次；参数格式错误，根据错误信息修正后重试；返回结果为空，换个工具或换个参数再试。这些都可以在编排层自动做，不需要打扰用户。

优雅降级的典型场景：Agent连续三次尝试都失败，这时候不应该继续硬试，而应该把当前状态和已尝试的方案告诉用户，让用户决定下一步。降级的关键是"信息透明"——用户要知道Agent做了什么、卡在哪里、有哪些选项。

明确报错的典型场景：任务本身不合法，或者超出了Agent的能力范围。这时候要明确告诉用户"这个我做不了"，而不是含糊其辞或者胡编一个结果。我见过太多Agent在能力不足时硬编答案的情况，这比直接报错危害大得多。

实操心得：给Agent设一个"最大尝试次数"，超过就停。我早期没设这个，结果有一次Agent陷入循环，调了同一个工具十几次，烧了不少token。后来设成3次，超过就转人工，问题解决。

4. 实操过程与核心环节实现

4.1 从一个具体场景开始：内部知识库问答的Agent化

我用一个真实改造过的场景来串一遍完整流程。场景是内部知识库问答——原来是一个RAG系统，用户提问，系统检索文档，拼接后让LLM生成回答。问题是：回答质量不稳定，复杂问题答不好，用户经常需要追问好几轮。

改造目标是：把"检索-生成"这个固定管道，改成Agent驱动的动态流程。Agent可以自己决定要不要检索、检索几次、要不要换个关键词再检索、要不要调用其他工具补充信息。

第一步：定义工具集。我定义了四个工具：search_docs（检索文档）、get_doc_detail（获取文档详情）、ask_clarification（向用户澄清）、summarize（总结）。注意ask_clarification这个工具很关键——它让Agent在信息不足时主动问，而不是硬答。

第二步：设计编排逻辑。核心循环是：理解问题 → 判断信息是否充足 → 不足则检索或澄清 → 充足则生成回答 → 检查回答质量 → 不合格则回到检索。这个循环最多跑3轮，超过就输出当前最好的结果并说明局限。

第三步：实现状态管理。用一个JSON对象存任务状态：原始问题、已检索的文档ID、已澄清的信息、当前回答草稿、尝试次数。每轮循环都更新这个对象，并注入到上下文里。

第四步：调优提示词。这一步花的时间最多。提示词里要明确：什么情况下该检索、什么情况下该澄清、什么情况下该直接回答、回答的质量标准是什么。我改了十几版才稳定下来。

第五步：评估和迭代。我准备了50个测试问题，覆盖简单事实查询、多文档综合、需要澄清的模糊问题、知识库外的问题。每改一版提示词或工具，就跑一遍测试集，看成功率的变化。

改造后的效果：简单问题的回答质量基本持平，但复杂问题的回答质量明显提升，用户追问轮数从平均2.3轮降到1.4轮。更重要的是，Agent在知识库外的问题上不再胡编，而是明确说"知识库里没有相关信息"。

4.2 关键参数的计算与选择

Agent系统里有几个参数需要仔细调，我把我用的值和计算逻辑说一下。

最大循环次数：这个参数决定了Agent最多尝试几轮。设太小，复杂问题处理不了；设太大，简单问题浪费资源。我的计算方式是：统计测试集里每个问题需要的平均轮数，取P90分位数再加1。我的测试集P90是2轮，所以设成3。这个值不是拍脑袋来的，是根据实际数据算的。

上下文窗口分配：假设模型窗口是128K token，我的分配是：系统提示词8K、工具定义4K、任务状态2K、对话历史20K、检索结果60K、生成预留34K。检索结果占大头，因为知识库问答的核心信息在这里。如果是其他场景，这个分配要调整。

工具调用超时：设成多少合适？我的经验是：内部工具3秒，外部API 10秒，检索类15秒。超时后重试一次，再超时就降级。这个值是根据实际监控数据调的——我统计了各工具的正常响应时间分布，取P99再加一点余量。

温度参数：Agent场景下我一般设0.1-0.3，比纯生成场景低。因为Agent需要稳定地做决策，不需要太多创造性。只有在生成最终回答时，可以适当调高到0.5-0.7，让回答更自然。

4.3 实操现场：一次完整的Agent执行记录

我把一次真实的执行记录脱敏后贴出来，让大家看看Agent实际是怎么跑的。

用户问："我们产品的退款政策是什么？海外用户适用吗？"

第一轮：Agent判断这个问题需要检索。调用search_docs，关键词"退款政策"。返回3篇文档，其中一篇讲国内退款政策，两篇讲海外业务。

第二轮：Agent判断信息部分充足，但海外退款政策的具体条款没找到。调用search_docs，关键词"海外 退款"。返回2篇文档，找到了海外退款的具体条款。

第三轮：Agent判断信息充足，生成回答。回答里区分了国内和海外两种情况，并引用了具体文档。

第四轮：Agent自检回答质量，发现海外部分的生效时间没提到。调用get_doc_detail获取那篇文档的详情，补充了生效时间。

第五轮：生成最终回答，输出。

整个过程5轮，耗时约8秒，调用了4次工具。如果按原来的RAG管道，这个问题大概率只能答出国内部分，海外部分要么漏掉要么编造。

注意：这个执行记录里，Agent的每一步决策都是基于当前状态做的，不是预先编排好的。这就是"重构"和"叠加"的区别——流程是动态生成的，不是固定的。

5. 常见问题与排查技巧实录

5.1 Agent不调用工具，直接编答案

这是最常见的问题。Agent明明有工具可用，却选择直接生成答案，结果答错了。

原因通常有三个：一是提示词里没有强调"必须基于工具返回的信息回答"；二是工具描述不够吸引人，Agent觉得没必要用；三是任务本身太简单，Agent觉得不需要工具。

排查方法：先看提示词，加上"对于事实性问题，必须先调用检索工具，不得凭记忆回答"这类硬性约束。如果还不行，看工具描述，把使用场景写得更明确。如果还不行，可能是模型能力问题，换个更强的模型试试。

我的经验是：这个问题80%靠提示词解决，15%靠工具描述优化，5%靠换模型。

5.2 Agent陷入循环，反复调用同一个工具

Agent调了工具，觉得结果不对，又调一次，还不对，再调一次……陷入死循环。

原因通常是：工具返回的结果和Agent的预期不符，但Agent不知道该怎么调整。比如检索返回空结果，Agent不知道是关键词不对还是知识库里真没有，就反复用同样的关键词检索。

解决方法：一是在工具返回里加上"如果为空，建议尝试XX"这类提示；二是在编排层设最大循环次数，超过就强制跳出；三是给Agent一个"放弃"的选项，让它知道可以承认失败。

我现在的做法是组合拳：工具返回带建议 + 最大循环3次 + 提示词里明确"如果连续两次检索无果，应该向用户澄清或说明局限"。

5.3 多轮对话中Agent"忘记"了之前的信息

用户在第一轮说了"我要订下周三的机票"，第三轮Agent却问"您要订哪天的"。

原因是上下文管理没做好。对话历史被截断了，或者任务状态没有正确更新。

排查方法：先看上下文窗口的分配，对话历史是不是留得太少。再看任务状态有没有把关键信息结构化存下来。如果都没有，那就是提示词的问题——没有告诉Agent"要从对话历史里提取关键信息并记住"。

我的做法是：关键信息（时间、地点、人物、数量）在提取后立即写入任务状态，不依赖对话历史。这样即使对话历史被截断，任务状态还在。

5.4 工具调用参数填错

Agent调用工具时，参数类型不对、格式不对、漏填。这是高频问题。

根本原因往往是工具的参数schema定义不够清晰。比如一个日期参数，schema里只写type: string，Agent可能填"下周三"这种自然语言，而不是"2024-06-12"这种格式。

解决方法：在schema里加format和description，明确格式要求。更好的做法是在工具实现里做参数预处理，把自然语言日期转成标准格式。这样Agent填什么都能work。

我现在的习惯是：所有工具的参数都做一层预处理，能容错就容错，不能容错就返回明确的错误信息告诉Agent怎么改。

5.5 常见问题速查表

5.6 几个不那么常见但很坑的问题

工具之间的依赖顺序。有些工具必须在另一些工具之后调用，比如先create_order再pay_order。Agent有时候会搞反顺序。解决方法是在工具描述里写明前置条件，或者在编排层做校验。

并发调用的状态冲突。如果Agent同时调多个工具，而这些工具会修改同一个状态，就可能冲突。我的做法是：默认串行调用，只有明确无依赖的工具才允许并发。

长任务的中间状态丢失。一个任务要跑几分钟甚至几小时，中间服务重启了，状态就丢了。解决方法还是持久化——每一步的状态都写数据库，重启后从最后一步恢复。

用户意图的歧义。"帮我处理一下这个"——处理什么？怎么处理？Agent需要澄清，但有时候它不澄清就直接猜，猜错了。解决方法是在提示词里强调"意图不明确时必须澄清"，并给澄清工具足够高的优先级。

6. 看不见的河床：Agent重构对团队和流程的影响

前面讲的都是技术层面看得见的东西。但Agent重构真正深远的影响，在看不见的地方——团队的分工、流程的设计、甚至产品的定义方式，都在变。

最明显的变化是：提示词工程师这个角色在淡化，编排工程师在崛起。早期大家觉得写好提示词就万事大吉，现在发现提示词只是冰山一角，真正的功夫在编排逻辑、状态管理、工具设计上。我团队里现在最缺的不是会写提示词的人，而是能设计好Agent工作流的人。

第二个变化是：测试和评估的复杂度上了一个台阶。传统软件的测试是确定性的——输入A，期望输出B。Agent的测试是不确定的——同样的输入，可能走不同的路径，输出也可能不同。我们现在的做法是建一个"行为测试集"，不只测最终输出，还测中间步骤的合理性。比如"是否调用了必要的工具"、"是否在信息不足时澄清"、"是否在失败时优雅降级"。

第三个变化是：产品设计的思路在变。原来设计产品是设计流程——用户先点这里，再点那里。现在设计产品是设计能力和边界——Agent能做什么、不能做什么、遇到边界怎么办。这听起来更简单，实际上更难，因为你要考虑的组合情况多得多。

第四个变化是：人机协作的边界在移动。原来很多需要人判断的事情，现在Agent能做了；但Agent做不了的事情，往往比原来更需要人。比如异常处理、复杂决策、情感沟通，这些反而变得更关键。我团队里现在有一个专门的"Agent训练师"角色，工作就是不断给Agent喂案例、调优、处理它搞不定的情况。

这些变化不是一夜之间发生的，但方向很明确。如果你在做Agent相关的项目，除了技术本身，也要关注这些"河床"层面的变化。技术会迭代，框架会过时，但这些底层的工作方式变化，影响会更持久。

7. 我踩过的几个大坑和最后的建议

说几个我印象最深的坑。

第一个坑：过早追求通用性。我一开始想做一个"什么都能干"的Agent，结果什么都干不好。后来收缩到具体场景，反而效果好。Agent的能力边界要清晰，不要贪多。

第二个坑：忽视评估。早期我靠感觉判断Agent好不好，结果改了一版提示词，感觉变好了，实际上在测试集上成功率降了。后来老老实实建测试集，每次改动都跑一遍，才稳定下来。

第三个坑：工具设计偷懒。直接把现有API暴露给Agent，结果Agent用得一塌糊涂。后来花了两周专门改造工具，成功率直接上了一个台阶。这个投入非常值。

第四个坑：不设成本上限。有一次一个Agent陷入循环，一晚上烧了不少钱。后来加了token上限和循环上限，再也没出过这种事。

如果让我给准备做Agent重构的人一条建议，那就是：从小场景开始，把一个小场景做透，再考虑扩展。Agent的复杂度不是线性的，一个小场景做透了，你积累的方法论可以复用到其他场景；一个小场景没做透就铺开，你会同时面对一堆问题，根本不知道从哪下手。

最后分享一个我最近在用的技巧：给Agent加一个"自我反思"的步骤。在生成最终回答前，让它自己检查一遍——信息是否充足、逻辑是否自洽、有没有遗漏。这个步骤会增加一点延迟和成本，但回答质量的提升很明显。我实测下来，加了这一步之后，用户满意度提升了大概15个百分点。这个投入产出比，我觉得很划算。