企业官网建设流程全解析

破题：如果你不崩溃，说明你还没做AI智能体

做了两年多AI智能体落地，我最大的感受是：每个号称“AI应用研发专家”的人，职业生涯大概都逃不过一次体面尽失的崩溃。不是测试不通过的崩溃，是那种线上用户疯狂反馈、模型乱调用工具、上下文被无关信息塞满、token账单像漏水的水龙头一样狂飙的崩溃。

我经历过，我所在的小团队也经历过。有一个做订单查询的Agent，前期DEMO跑得风生水起，结果投到生产环境后第三天的中午，它连续调了四十多次退款接口，差点把一批真实的订单状态给改了。那天下午我盯着日志，后背全是冷汗。后来我们花了两周时间重构，把整套思路全部推翻，才有了这套被我们内部称为“进阶五级法则”的框架。

这篇文章不是讲理论，是我和团队踩坑踩出来的实战总结。我不会把Agent夸成“无所不能的自动驾驶”，恰恰相反，真正的进阶是从承认它不可靠开始的。下面我会拆解这五个阶段：混沌阶段、结构阶段、受控阶段、可观测阶段、工程化阶段，每个阶段要解决什么问题、用什么手段解决、踩过哪些坑，一个不落。

1. 从崩溃现场开始拆解：智能体为什么总会跑飞

1.1 先看点真实的崩溃现场

我做过的Agent项目里，出现过这些非常典型的失控场景：

• 角色乱入：明明是客服机器人，一句话没说对，突然开始在回复里扮演“一名资深心理学专家”。你要求它代入角色，它把整个背景故事都脑补出来了。
• 工具狂魔：需要查天气的请求，它先去调了余额查询接口、再去调了订单列表接口，转了一圈回来告诉你“天气数据暂不可用”。
• 上下文爆炸：一个会话跑了三小时后，大模型把几千条历史消息全部塞进上下文窗口，单次请求的token费用翻了二十倍。
• 指令失忆：你在系统提示词里写得一清二楚“只允许调用查询类工具”，结果用户问了一句“你能帮我退款吗”，它就真的开始准备调用退款接口。

这些问题的共性只有一个：你让大模型在无人区里裸奔。你给它的自由度太高了，指望它自己能处理好边界、能理解业务、能做出正确的规划决策。问题是，大模型的能力边界是概率性的，它可能90%的时候都能选对，但剩下的10%，恰好就是最致命的场景。

1.2 为什么会崩：智能体两个“认知”严重错位

崩到怀疑人生之后，我花了很长时间揪根本原因。表面上是“模型不行”，往深了挖，其实是两个错位：

第一个错位是：你把它当“自动驾驶”，它其实只是个“语言世界模拟器”。大模型对业务规则的理解，完全来自文本描述。你在提示词里写“这个很重要”，在模型眼里只是一些字符串。它不懂什么是“订单状态不能变更”、什么是“资金操作必须二次确认”，如果你不把约束变为显性的规则，它就靠猜。

第二个错位是：你给的“规划自由”超出了它能力的承受范围。开放式的“请帮我处理订单”，远比“根据当前状态，选择一个可执行的动作”要难得多。给大模型越大的决策空间，它出错的机会就越多。

想明白了这两点，重构的方向其实就一句话：把Agent从“独自开车”变成“在铁轨上开车”。你有轨道，它有动力，失控的概率就会小很多。

2. 五级法则总览：进阶路径就是权力回收的过程

我先说结论。这套五级法则的核心思路，是逐级把“决策权”从大模型手里收回，交给代码、规则、显式的数据流和可观测系统。收回不是为了削弱Agent，而是让它在有限的自由度里做擅长的事：理解语言、拆解表述、生成回复。

这个表格是我在多个项目里反复修订后的版本。可以看到，越往上走，系统的“工程浓度”越高，模型在其中的“角色浓度”反而下降了。有朋友问我：“那我还用大模型干嘛？”我的回答是：模型的角色不是决策者，而是组件。就像CPU是电脑的核心，但电脑能不能稳定运行，取决于主板、内存、电源、操作系统，而不只是CPU。

3. L1到L2：从“一段提示词走天下”到“状态机驱动”

3.1 混沌阶段的典型姿势

混沌阶段的Agent长什么样？很多团队的初版都是这样：

• 一整个系统提示词几千字，包含人格设定、业务知识、工具清单、使用规则、输出格式。
• 没有任何中间状态，模型根据全部历史对话直接生成下一步动作。
• 工具调用靠模型自己“想起”，没有强制校验，没有执行前检查。

说实话，这种结构在Demo阶段真的能跑，而且因为大模型的理解能力强，有时表现得还挺惊艳——客户看到它自己查了库存又查了价格，还自然地说了一句“您的商品我们这边有现货”，当时觉得AI无敌了。

但生产环境是另一回事。

我们的客服Agent上线第一天，用户问“我的订单为什么还没发货”，Agent正确查了订单状态，发现是“待付款”，按理该回答“您的订单尚未完成支付”。结果它不知道从哪里联想了上下文，认为用户很急，竟然去查了物流公司的公共接口，然后回复“您的包裹正在从上海发往北京”。用户当然开心，但实际上这个订单根本没付款，造成了严重的信息误导。

3.2 重构第一板斧：把“自由对话”改成“状态机”

L2的核心动作，是收敛Agent的行为空间。怎么做？把业务流程拆成确定性状态，模型只能在当前状态允许的动作中选择。

拿订单Agent举例，我们定义了这些状态：

1. GREETING（初始问候）：只允许识别用户意图。
2. AUTH_CHECK（身份确认）：只允许向用户索要订单号或手机号。
3. ORDER_QUERY（查询处理）：只允许调用订单查询工具，并基于结果生成回复。
4. AFTER_SALES（售后意图识别）：只允许收集用户诉求，不能直接执行任何变更操作。
5. HANDOFF_HUMAN（转人工）：触发条件，将上下文完整打包给人工。

在代码里，我们用一个简单的状态表来管理：

STATE_TRANSITIONS = { "GREETING": { "intent": ["query_order", "after_sale", "human_handoff"], "next_state": ["ORDER_QUERY", "AFTER_SALES", "HANDOFF_HUMAN"] }, "ORDER_QUERY": { "action": ["query_order_status"], "next_state": ["GREETING", "AFTER_SALES", "HANDOFF_HUMAN"] }, ... }

大模型只负责做两件事：从当前状态允许的动作集合里选择一项；根据查询结果生成自然语言回复。剩下的所有跳转逻辑、边界控制，都由代码说了算。

这样做有一个立竿见影的效果：模型的自由发挥空间被砍掉了80%，之前那种乱调接口、乱下结论的概率大幅下降。

3.3 状态机不是银弹，注意这四个坑

状态机的重构思路虽然有效，但也不是拿来就用，这里有几个我们踩过的坑：

• 状态不要分得太碎。我们曾经把订单流程拆成十二个状态，结果模型频繁在状态之间跳错，用户问了一句无关的话，Agent就卡在了某个中间态。后来合并成五个主要状态，问题解决。经验：状态粒度以“用户可感知的业务步骤”为准，不要拆到内部操作的细节。
• 状态必须带超时和兜底。用户在一个状态里停留太久没输入，或者输入和当前状态完全无关，必须有明确的转移规则，否则系统会卡死。我们的兜底策略是：只要无法明确匹配意图，一律转向“澄清意图”子状态，最多问两次，然后转人工。
• 状态机需要处理“乱入型输入”。比如用户在查询订单时突然问“今天天气怎么样”，我们的方案不是让模型直接回答天气，而是让它识别出这是无关意图，回复“我暂时只能帮您处理订单相关的问题，如需其他帮助可以转人工”。
• 关键跳转动作需要人工确认。这里重点说资金类操作、信息修改类操作。原来的流程里“只读查询”到“变更操作”之间，必须加入一个显式的确认状态。我问了一圈做Agent的同行，这个坑几乎人人踩过。

3.4 给L2阶段一个可抄作业的模板

如果你们团队刚准备做L2重构，我建议按这个顺序来：

1. 把现有Agent所有能执行的动作列出来，按风险等级排序。
2. 根据业务目标，定义三到七个用户可见的状态。
3. 为每个状态制定“允许动作清单”和“转移条件”。
4. 把状态表固化成代码，模型输出必须先映射到合法动作，再执行。
5. 对每个状态，设计至少一个“兜底动作”，确保系统不会卡死。

做完这一步，你会明显感觉到，Agent像换了一个人——废话少了，动作精准了，不再随便脑补了。但冷静一点，L2只解决了“选择混乱”的问题。工具调用本身还会出问题。

4. L3：工具调用收口，把“会调”变成“调不错”

4.1 工具调用的隐患比你想的大

到了L2阶段，Agent能在状态机允许的范围内选择工具了，但新的问题浮出水面：工具本身不设防。

我们当时的Agent可以调用一个“发送优惠券”的工具。在状态机的约束下，它确实只会在用户表达领取意愿时触发。但问题是：它可能把同一个用户重复触发了好几次，导致同一个手机号领了五张券。更有意思的是，促销活动结束后，模型“记住”了优惠券这个功能，在新对话里还给用户推已经过期券。这不是状态机的锅，是工具调用缺少边界检查：

• 没有频率限制，同一用户一分钟内最多调用几次，没有定义。
• 没有状态前置检查，工具依赖的上下文在调用时是否仍然有效，没有检查。
• 没有输入校验，该传数字的参数传了负数，该传枚举值的参数传了随机字符串。

4.2 我们在工具层做了四件套

为了让“调用工具”这件事变得可靠，我们形成了一套标准做法，我给命名为“工具防抖四件套”：

第一件：统一JSON Schema，严格参数类型。

每个工具必须注册一个完整的JSON Schema，字段类型、枚举范围、格式约束全部写死。大模型输出后，我们先做schema校验，不合法直接报错让模型重试，不让它带病执行。有人觉得这样会降低交互顺畅度，但实测下来，模型重试一两次基本都能通过校验，比放任它乱传来得值。

第二件：执行前置检查与幂等保护。

在执行工具之前，代码要检查业务前置条件。还是以发券为例，先查这个手机号是否已在当前活动里领过券，领过就拒绝执行，并让Agent友好回复用户。幂等性尤其重要，我们的退款工具就吃过亏——Agent因为上游超时而重试，结果产生了多笔退款记录。后来在工具层补充幂等键，一次退款请求带上唯一的业务ID，重复请求直接返回原结果。

第三件：超时、熔断与最大调用次数。

一个Agent会话里，我们强制设了单轮工具调用上限（比如5次）、单会话最长执行时间（比如3分钟）。一旦超限，立即终止循环，转入人工兜底。这个参数不是我拍脑袋定的，是我通过统计线上正常会话的调用分布算出来的：95%的正常会话，工具调用次数在3次以内。把上限设为5次，既不影响正常用户，又能精准圈住无限循环的异常会话。

第四件：执行结果格式标准化与错误注入。

工具返回的结果，不管是成功、失败、还是超时，都必须是一个结构化的标准格式，比如：

{ "status": "success", "data": { "order_id": "20250101", "status": "PAID" }, "error": null }

我们要求每个工具实现者提供“可能出现的错误类型清单”，逐条测试Agent在每种错误下的反应。这个工作量大，但极其值得——很多Agent在工具报错时会自己脑补一个错误原因，就是因为它没有见过真实的错误返回。

4.3 参数怎么定，不能拍脑袋

我在L3阶段最想强调的一点是：所有约束参数，都应该从真实日志里榨出来，不是想出来的。

我们第一次设置工具调用上限时，我拍脑袋写了10次。结果上线后日志显示，有一类复杂售后场景，正常用户会连续触发六到七次工具调用，直接被我的限额误伤了。后来我把线上日志拉出来跑了一遍分布统计，按P95的阈值去设，才定下5次这个值。同理，时间超时、并发数、上下文长度上限，都应该遵循同样的方法：先放开记录，再按统计收紧。

有一个朋友问我：要不要在Prompt里直接写“只允许调用XX工具”？我的建议是：Prompt里当然可以写，但绝不能只靠Prompt。Prompt是软约束，模型可能忘、可能误解、可能被用户话术带偏。最可靠的做法是软硬结合——Prompt负责引导，代码层负责强制。代码才是最后的闸门。

4.4 L3阶段的排查示例

举一个我们线上修复过的真实问题：某个Agent会话中，用户说“我昨天买的东西坏了”，Agent判断这是售后意图，调用了“查询最近订单”工具。结果工具返回了两个订单（用户在半小时内下了两单），Agent没有让用户选择是哪一单，直接选了第一个订单发起售后流程，并给用户发了退货地址。

用户一头雾水：“我没说要退第一个订单啊。”

问题出在哪？工具返回了多条数据，但Agent没有“澄清歧义”的动作。我们的修复方案是：在工具返回中，如果命中数超过1，强制Agent进入“澄清子状态”，把所有候选项列给用户，直到用户确认唯一目标后才继续。这个逻辑放在状态机里，而不是靠提示词约束。

类似的案例还有很多。总之，L3阶段的目标是让工具调用变成可控的、可预期的、有边界的操作。做到这一步，Agent才算是从“裸奔”进入“戴上了安全带”。

5. L4：可观测性，没有日志链路的Agent等于裸奔

5.1 项目里最痛的那一刻

有一次线上事故：Agent在一小时内给同一位用户发了13条短信，被用户截图投诉到平台。我们排查时傻眼了——回顾对话历史，只看到一条工具调用记录，根本不知道短信为什么发了13条。最后翻遍了各个服务端的日志，才发现是Agent内部规划循环了，它以为上一次没有成功，反复重新执行发送动作。

这次事故让我彻底明白：Agent的逻辑链路跨越了模型调用、工具调用、状态跳转、外部API等多个环节，任何一个环节没有日志，出了问题就是两眼一抹黑。

5.2 智能体追踪的标准化结构

在L4阶段，我们给每个会话增加了一个结构化追踪对象，类似分布式追踪里的trace概念。每一轮Agent执行，都记录以下字段：

• session_id：会话唯一ID。
• turn_id：本轮交互的序号。
• state：进入本轮的Agent状态。
• input：用户输入归一化后的内容。
• model_action：模型实际输出的原始动作。
• chosen_tool：最终选择执行的工具名。
• tool_args：实际传给工具的完整参数。
• tool_result_summary：工具返回的摘要（保留全量在明细表里）。
• token_usage：本轮模型调用消耗的输入/输出token数。
• latency：本轮总耗时。
• error_type：如果有异常，记录异常类型。

有了这套结构，查问题时效率完全不一样。以前是“翻日志大海捞针”，现在是“按session_id查一遍还原现场”，连模型当时想了什么、输出过什么、在哪里走了岔路，全部一目了然。

5.3 四个必须盯的指标

除了链路日志，L4阶段我还建议团队在仪表盘上长期盯四个指标，它们能暴露Agent的大部分健康问题：

我特别想强调“单会话Token消耗”这个指标。Agent最大的隐藏成本杀手就是上下文无限膨胀。我们见过一个会话持续了三天，历史消息一万多条，一次请求要消耗大约30万token。后来我们强制增加了上下文压缩策略：对话超过20轮后，把早期对话做摘要，把工具返回的明细结果裁剪成关键字段，把无用的中间状态清掉。这一步做完，单会话成本直接降了六成。

5.4 测试与回归：先把“地基”打牢

L4还有一个容易被忽略的环节：离线回归测试。

我见过很多团队夸Agent“效果不错”，但问他们“拿什么证明”，得到的答案是“我们试了几个case，感觉还行”。这不行。Agent是概率系统，一次两次效果好不能说明任何问题。我们的做法是建了一个回归集：把线上真实用户场景脱敏后整理成大约200个测试样例，每个样例包含用户输入、期望状态、期望调用的工具、期望回复的关键信息点。

每次修改系统提示词、调整状态机、更换模型版本，都先跑一遍这个回归集，对比动作正确率、工具选择准确率、回复信息完整率。没有回归集就开始改线上配置，那就是开盲盒。

我自己经历过一次毫无防备的“模型悄悄升级”：平台在大版本升级后，某个模型对工具参数的理解能力下降，同一个问题之前能正确选择参数，升级后频繁传错。如果没有回归集，这类问题可能要线上用户先发现。锁定版本、固定回归、灰度切换——这三件事在做Agent时一样都不能少。

6. L5：工程化的终局——把Agent当作产品来迭代

6.1 Agent系统也是产品，不是“一个模型”

走到L4，系统其实已经相当稳定了。但真正的考验在于：当你的Agent从“一个功能”变成“一个产品”，你敢不敢持续迭代？

我们有个客服Agent，上线三个月后，业务方不断提出新需求：新增退货进度查询、支持语音输入转文本、接入新的促销活动规则。如果还是每次手工改提示词、手工测一遍，根本跑不过来。

L5阶段的思维方式是：把Agent当成一个可以持续演进的产品系统来运营。

6.2 五步闭环迭代法

我们内部形成了五步迭代闭环，每个功能需求都照这个流程走：

1. 需求转写：把业务需求拆成状态变更和工具变更。新增“退货进度查询”，意味新增一个状态、一个工具、三个话术模板。
2. 开发与构建：按L3的标准实现工具和校验，按L2的标准更新状态表。
3. 离线回归：在新功能样例加入回归集后，跑全量回归，确保旧功能不退化。
4. 影子发布：新版本在线上环境运行，但只记录决策日志、不实际执行业务动作。跑一周，对比新旧两个版本的差异。
5. 灰度放量：先放10%流量，观察核心指标2天，确认无异常后逐步放量。

影子发布这个机制特别有用。它让你在真实流量上看到新版Agent的表现，又不承担风险。我们曾经在影子阶段发现新版Agent在个别场景里工具选择完全错误，幸亏没有直接全量上线。

6.3 评测体系：不要靠“感觉”做决策

L5必须有数据支撑的评测体系，否则团队很容易陷入无休止的争吵。我们用的指标如下：

• 动作正确率：Agent选择的状态和工具是否正确。
• 回复信息完整率：关键信息（订单号、金额、时间等）是否在回复中全部出现。
• 流程走通率：一个会话能否在限定轮数内走完完整业务流程。
• 人工介入率：必须转人工的比例，越低越好，但不是绝对指标。
• 成本效率：单次成功会话的平均token开销、平均工具调用数。

有了这些指标，业务方提需求时就能做量化对比：新功能上线后，人工介入率从6%降到了2%，这就是价值，讲得清楚。而不是“AI变聪明了”这种玄学。

6.4 组织协作：没有“Owner”的Agent必死

最后说一点代码之外的事。一个长期运转的Agent系统，必须有一个明确的负责人角色。这不是搞组织架构，是明确责任边界。没有负责人的系统，出了问题四处推诿；有负责人，迭代才会有节奏。

我们团队的做法是：每个核心业务Agent配一个“Agent产品经理”角色，负责收集业务反馈、排定需求优先级；一个“Agent工程师”角色，负责改动状态机、工具、提示词；还有专门做评测的人，负责维护回归集、跑离线与影子评测。三个人一个小分队，就能把一条Agent业务线长期稳定地运营下去。

再比如，我们还会为每个Agent维护一个“已知问题清单”。线上用户反馈的所有异常，无论大小，全部登记在案，每周评估一次，分成“轮修”“待观察”“可忽略”三类。这听起来很琐碎，但很多Agent项目崩就崩在缺少这种运营机制——上线后没有人管它，效果自然越来越拉垮。

7. 实战警示录：五个最该避免的“崩溃操作”

这五级法则讲完，我想附一个“反面清单”，都是我和同行血泪换来的教训，希望能让大家绕开这些坑：

1. 不要拿生产环境当测试环境。任何提示词、状态机、工具参数改动，都必须先离线回归、再影子发布、最后灰度。不要觉得“改个提示词而已，没关系”，模型是概率系统，一点变化可能引起连锁反应。
2. 不要让Agent直接执行高风险操作。涉及资金、隐私、权限变更的动作，至少要加一道“人工确认”状态。哪怕加了状态会损失一点“AI感”，安全性远重要于炫技。
3. 不要忽略上下文增长。一定要设对话轮数上限、摘要压缩策略、Token消耗告警。成本失控是很多Agent项目被中止的主要原因。
4. 不要相信模型自己解释自己。在执行前和重试时，模型给的理由不一定是对的。要靠代码校验和日志还原，而不是指望模型反思能解决问题。
5. 不要停止迭代。Agent上线不是终点，交互数据会不断告诉你哪里需要改进。固定节奏，持续优化，才是工程化的意义。

另外，如果你想验证一个Agent系统是否达到了L5，我还有一个独门“土办法”：把整个Agent系统停掉一个小时，看多少业务会受到影响，需要多长时间恢复。如果停了一个小时业务完全不受影响，说明Agent还没真正融入业务价值。如果真的影响巨大，但没有预案、没有负责人、没有快速回滚机制，那说明工程化尚未完成。这个测试我们每季度做一次，每次都能暴露一堆问题。

8. 最后的真心话

写到这里，回想这两年从崩溃到重构的过程，我最大的体会是：做AI智能体，真正的难点从来不是大模型本身，而是围绕模型建立起来的这套系统工程。

模型只是一个零件，而且是一个有一定随机性的零件。你把它焊在状态机的轨道上、加装工具校验的护栏、部署可观测的仪表盘、建立评估迭代的流水线，它才真正变成可用的产品。崩溃本身不可怕，可怕的是崩溃之后还在用同一种方式继续试。

如果你正在为一个失控的Agent头疼，我建议就从L2开始——先把状态机建起来，把模型的决策空间收窄一半，你会看到立竿见影的变化。那扇门一旦推开，“重构”的路就没有想象中那么难了。无论是技术框架还是协作机制，这套五级法则都值得你在自己的项目里试一遍。