企业官网建设流程全解析

1. agent-native 不是又一个营销词：它重构了"谁在做决策"

去年我们把用了三年的订单处理管线拆掉，换成了由大模型自主编排路由逻辑。上线第一周，问题清单比过去三年加起来还长：有订单被重复扣款，有物流状态查得驴唇不对马嘴，还有 agent 在晚上十一点给客户发了一条措辞非常不合适的催付短信。但把这些故障一个个理清楚之后，我反而成了 agent-native 最坚定的推动者。

因为问题恰好指出了旧架构的核心矛盾：所有业务逻辑都被硬编码成一系列 if-else 和顺序步骤，一旦需求变化，改一个分支就要发一版，而真正复杂的长尾场景又根本没法枚举完。agent-native 的思路很简单——把"流程怎么走"这件事的决定权部分交给智能体，让模型根据当前输入、工具返回和预设目标自主规划下一步。我之所以强调"部分"，是因为完全放手那是实验玩具，不是生产系统。

我现在对 agent-native 的理解可以浓缩成一句话：它不再以代码分支为系统的第一公民，而是以智能体为第一公民，代码和工具退化为智能体手里的积木。这篇文章把我在迁移过程中的设计逻辑、踩坑经历和排查方法完整写出来，适合正在做 Agent 应用、或者准备把现有规则引擎改造成智能体架构的团队参考。

1.1 一个让我彻底改观的线上故障

事故的触发点是一个很简单的小功能：用户申请改收货地址。旧实现是一段约 80 行的状态机代码，先查订单状态，再校验是否已发货，然后调地址服务更新，最后给用户发通知。

agent-native 重构后，这段逻辑变成一个 tool-calling 循环：模型收到"我想改地址"这句话，自己决定先调 check_order_status，再调 check_shipped，接着调 update_address。意外出在第二步：agent 在一次测试中跳过了 check_shipped，直接 update_address，把已经进入配送流程的订单地址改了。货送到了旧地址，用户投诉，客服介入。

当时第一反应是"这模型不行，赶紧回滚"。但冷静看数据后发现，同一周内 agent 处理了 2000 多个地址变更请求，只有这一例出错，而它之所以出错，是因为工具描述里没写清楚 update_address 的适用前提。这不是模型能力问题，是我对 agent-native 的理解还停留在"把工具堆给模型就行"的阶段。

这个案例让我意识到：在 agent-native 架构里，系统设计的主战场从"代码逻辑"转到了"工具契约"。模型不是不可靠，而是我们对它的约束方式不对。这个认知转变，决定了后面整个架构的改造方向。

1.2 接口思维与目标思维的本质区别

传统开发者的思维习惯是"接口思维"：把业务拆成输入、处理、输出，每一步都有明确的前置条件和后置条件。接口思维的优势是可预测、可测试、可审计，劣势是它假设所有流程都可以在写代码那一刻枚举穷尽。

agent-native 引入的是"目标思维"：我只告诉智能体"用户想改地址，你要保证地址在配送前被更新"，具体先查什么、后调什么、要不要确认，由模型根据实时信息决定。目标思维的优势是能覆盖长尾场景，用户换一种问法、多绕一个弯，模型都能兜住；劣势是结果有了概率性，不再 100% 可预测。

我画过一张对比表，贴在项目白板上：

这两种思维不是替代关系，而是一个系统的不同分层：确定性的、必须强约束的环节用接口思维，需要弹性处理的环节用目标思维。我后来反复强调的所谓"hybrid 架构"，本质就是把这两者在合适的边界上接起来。

1.3 为什么叫 agent-native，而不是 AI-native

很多文章把 AI 接入应用叫 AI-native，这两个概念我建议严格区分。AI-native 指整个应用从底层设计和体验上都以 AI 能力为优先，比如搜索引擎直接理解自然语言查询，但决定去检索哪些网页的仍然是人写好的检索策略。

agent-native 更近一步：应用不但接受 AI 能力，还把业务流程中"下一步做什么"的决策权交给一个自主行动的智能体。换句话说，AI-native 的系统里有 AI 组件，但组件处于被编排的位置；agent-native 的系统里，智能体本身是编排者。

打个比方：AI-native 是把发动机从老式螺旋桨换成了涡扇，飞机还是要靠飞行员手动航线；agent-native 是直接给了飞机一个自动驾驶系统，飞行员只在起飞和降落时介入。对这个差别的理解直接影响架构分层：如果只是 AI-native，你保留原来的流程引擎，只替换其中某些步骤的算法；如果是 agent-native，你就要重新设计状态管理、工具接口、监控告警和权限模型，这是完全不同的工程量。

2. 构建 agent-native 应用的四个支柱：编排、工具、记忆与护栏

把 agent-native 落地成能上生产的系统，不能只靠调 prompt。我拆过十几个项目以后总结出四个必做的基础设施层：编排层、工具层、记忆层和护栏层。每一层都决定了 agent 的行为边界和稳定性。

这不是一个"最佳实践清单"式的东西，而是我经过多次返工后得出的必要结构。少任何一层，系统都能跑 demo，但活不过线上。

2.1 编排层：单 agent 还是多 agent，取决于图的连通度

编排层要回答的第一个问题是：你只需要一个自由行动的智能体，还是需要多个智能体协作。我的判断依据是看"工具调用图"的连通度：当你把所有工具看成节点、把"这个工具的输出可能被另一个工具使用"看成边，如果边的数量超过 20，或者存在明显专业领域隔离，请拆成多 agent；如果工具的依赖关系相对线性，单 agent 完全够用。

举个例子：我做过一个客服系统，初期只有 5 个工具，分别是查订单、查物流、查优惠券、退款登记和转人工。工具之间没有强制先后关系，单 agent 处理得很好。后来增加了供应链工具、供应商结算工具、售后赔付工具，这些工具的知识专业度完全不同，退款登记和供应商结算虽然都涉及钱，但风险等级、审批流、操作人权限都不一样。此时再让一个 agent 掌握全部工具，prompt 会越写越长，模型还可能拿着供应商结算工具去处理用户退款。

多 agent 的拆分方式我也建议遵循"领域+权限"双维度，而不是按功能数量平均划线。一条实用的拆分规则是：每个 agent 有明确的核心职责声明，只允许调用自己域内的工具，跨域操作必须通过一个 supervisor agent 中转。这个模式天然搭好了权限隔离的架子，后面做安全审查时能省很多事。

2.2 工具层：让 agent 能正确使用工具，而不是把工具当话题

工具层是 agent-native 架构中最容易做砸的地方。很多人把工具层理解为"写几个 Python 函数，然后告诉模型这里有函数可以调"。但模型不是你团队的实习生，它不会通过函数名猜出你的业务约定，更不会替你做参数校验。

我的经验是工具接口要遵循"契约式设计"：每一个工具必须有清晰的三段式描述——触发条件、行为动作、返回结果。触发条件说明"什么场景下你才应该调用这个工具"，行为动作说明"调用之后会发生什么副作用"，返回结果说明"模型应该从返回值里提取什么信息来继续规划"。

下面是我常用的一个工具定义示范（以查物流为例）：

{ "name": "get_delivery_status", "description": "仅当用户询问包裹物流进度且已提供订单号时调用。调用后返回最新的物流轨迹和预计到达时间。不要主动调用该工具来闲聊天气或推荐商品。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，须形如ORD20250101" } }, "required": ["order_id"] } }

注意 description 里的"不要"和"仅当"。这是我从教训里总结出来的：模型不会因为你给了它一个工具就克制，它倾向于把工具描述里提到的任何信息都当成可聊话题。把边界写进描述，比试图靠通用系统 prompt 约束它可靠得多。

2.3 记忆层：会话记忆与业务记忆必须分开存

记忆是 agent-native 里最容易引起性能雪崩的地方。很多团队的第一个版本是把所有历史消息和工具返回一股脑塞进上下文，结果 token 成本线性上涨，上下文窗口被无关信息占满后，模型开始丢指令。

我目前的经验是把记忆分成两层：会话记忆和业务记忆。会话记忆指当前一次任务内的短期上下文，比如用户刚刚提供了什么信息、上一次工具返回了什么结果，这种记忆放在会话级缓存里，比如 Redis，只保留必要的字段。业务记忆指跨会话的长期知识，比如用户偏好、历史投诉记录、该客户的等级与信用额度，这种记忆放在向量库或结构化存储中，需要时通过"记忆检索工具"主动拉取，而不是全部塞进系统 prompt。

一个计算示例：假设每条会话消息 500 token，10 轮下来就是 5000 token；如果再叠加 20 条历史会话，就是 15000 token。按每 1000 token 成本约 0.005 美元计算，一个请求成本已经从 0.03 美元涨到 0.08 美元，放大到日均 10 万请求，费用差异非常可观。而用"按需检索业务记忆"的方式，每轮请求只多消耗一次检索工具的输入输出，成本和时间都低一个数量级。

记忆层的核心原则是：让模型记住它该记住的，让存储替它记住不该占上下文的。我见过太多 agent-native 项目死在记忆设计不当引发的上下文爆炸上，这一层值得你花整块时间专门设计。

2.4 护栏层：成本、权限、规则三者缺一不可

护栏层是 agent-native 和普通聊天机器人的分水岭。普通聊天机器人不需要护栏，因为它不产生副作用；agent-native 应用会调用工具、修改数据、影响真实业务，没有护栏等于让一个实习生直接操作生产库。

我通常建设三道护栏，按从低到高的层次排列：

第一道是权限护栏：agent 用什么身份、拿什么 token 去调用下游服务。永远不要给 agent 一个全局管理员角色，而是给它一个最小权限账号，同时把写操作和读操作分到不同工具。比如查询工具用只读数据库账号，更新工具通过独立的 API 网关，网关层再做一次字段白名单校验。

第二道是成本护栏：给每个 agent 配置最大迭代轮次、单轮最高 token 预算、单任务成本上限。我踩过的典型例子是 agent 在检索失败后反复重试同一工具 17 次，直到把 10 万 token 烧完才报错。现在我的默认值是 max_iterations=10，某个工具连续失败超过 2 次就触发暂停并转人工。

第三道是规则护栏：把不可逾越的业务红线编成可执行的校验器。比如"取消订单必须经过用户二次确认""退款金额超过 5000 元必须走审批工具"，这些规则不要指望模型自觉遵守，而是在工具调用链路上显式拦截。实现方式可以是在工具层加一个前置校验函数，也可以用一个 policy agent 监控执行轨迹。规则护栏的本质是把"不能做"从 prompt 里的软约束变成系统里的硬约束。

3. 把一条硬编码管线改成 agent-native 后，我踩到的真实坑

这一章我完整记录三个高频坑和一个排查链路。它们不是网上文档里那种浮在表面的建议，而是我真实经历过的、花了时间和成本才定位到根因的问题。

我建议你把这章当故障复盘读，而不是当教程读。因为 agent-native 的坑往往不是教科书式因果，而是一个环节的偏差经过模型放大后变成完全不同的症状。

3.1 坑一：agent 把工具当话题，而不是当操作

症状最早出现在聊天场景。用户问"你们发货到浙江要几天"，我们的 agent 居然调用了 get_delivery_status，还把这个工具描述里的"预计到达时间"字段直接当成回答模板，返回了一大段半截物流信息，读起来像系统故障。

原因出在工具 description 写得太开放："根据订单号查询物流信息并返回预计送达时间。"模型收到一个关于"几天能到"的问题，没有订单号，但是工具名和描述里包含"时间"，它就把问题映射成了工具调用。

修复方案是重写描述，明确"必须有订单号才可调用，没有订单号时不得调用"。同时把 get_delivery_status 从普遍路由模板中移除，只在检测到订单号语义时才注入工具列表。这个修改上线后，同类误用率从 12% 降到了 1% 以下。

这个坑的核心教训是：模型的工具选择逻辑非常依赖名字和描述的字面匹配，你必须比写给人看的 API 文档更加严谨，把"什么时候不调用"也写清楚。模糊一点，模型就会替你发明一种用法。

3.2 坑二：固定顺序流程被 agent 重新编排后出现前置校验缺失

这是 1.1 节里改地址那个故障的另一个变体。我们原本有一整套订单流转管线，前置校验、库存锁定、支付回调、发货通知各有先后。引入 agent-native 后，我把这些步骤都开放成了工具，希望 agent 可以根据用户需求灵活组合。

问题在于，agent 的灵活性本质上是"当前上下文驱动"的。当上下文里没有反复强调"必须先查库存再创建订单"时，模型在 5% 左右的请求里会只执行部分步骤，用户没有选择加急，它也没调加急服务，一切看起来很合理，但系统的业务不变量被破坏了。

我的解决方案很反直觉：把那些存在硬依赖的步骤重新固化成"组合工具"。比如"下单"不再是一个自由工具，而是一个编排工具，内部固定按"查库存→锁库存→创建订单→返回订单号"执行，agent 只能看到这个组合工具，不能看到中间的原子步骤。这样一来，模型的自由编排只发生在真正的决策点上，而关键业务链路仍然具备确定性。

这条原则我后来一直在用：硬件依赖用组合工具锁死，软决策留给 agent。不是所有步骤都应该开放给模型，越灵活的架构越需要知道哪里有铰链。

3.3 坑三：重试引发的成本爆炸

成本爆炸的案例发生在一个数据清洗任务上。agent 需要从 PDF 里抽字段，然后调用一个清洗工具。清洗工具偶尔因为格式问题抛异常，agent 收到报错后，自己没有读懂异常里面的 schema 不匹配信息，反而把同样的请求原样重试，连续 9 次，直到把上下文 token 耗尽才放弃。

我统计过运行时数据，异常重试消耗的 token 占到全系统消耗的 23%，这是个非常惊人的比例。监控告警的阈值是单任务成本超过 1 美元，这个任务瞬间飙到 3.6 美元，对成本来说也是个小事故。

处理办法有三层：第一层，给所有工具调用加上明确的重试政策，在 prompt 里写明"同一个工具调用失败后，不要盲目重试，先尝试理解错误信息或换一个方案"；第二层，在工具端做幂等控制，同一个 request_id 重复调用直接返回上一次的结果，不给 agent 重复扣款的机会；第三层，在护栏层设置单工具连续失败次数上限为 2，超额后强制中断或转人工。

成本爆炸的本质不是模型笨，而是 agent-native 应用让失败从"一次异常"变成了"一次异常×模型的重试热情"。你必须尽早引入幂等和配额机制。

3.4 完整排查链路：从一条可疑轨迹反推根因

当 agent-native 系统出了业务问题，最忌讳直接去看模型最终的输出是否正确，而要去看完整的执行轨迹。我给你一套我实际使用的排查顺序：

第一，从业务投诉拿到发生时间和用户 ID，回放该次会话的 trajectory 日志。日志里必须包含：每次 LLM 调用前后的完整消息、每次 tool call 的名称与参数、每次 tool 的返回值、模型在各步骤的中间思考过程。没有这份日志，任何排查都无从谈起。

第二，标记所有 tool call 的先后顺序，和预期流程对齐。比如改地址场景，标准动作是 check_order_status → check_shipped → update_address，如果日志实际顺序是 update_address → check_shipped，问题大概率出在工具层描述或模型规划能力。

第三，看工具输入输出是否有异常字段。有一次我们发现模型把用户地址"3号楼 1002 室"传成了"3 号楼 1002"，少了一个空格，导致下游服务解析失败，引发了更严重的连锁反应。

第四，对比相似成功案例的轨迹。如果同样输入、同样上下文，其他 99% 的轨迹都走对了，说明问题不是系统性的模型失误，而是一个概率边界案例。这时候再去看那 1% 的上下文里有什么特殊 token 或者用户措辞，几乎每次都能定位到 agent 触发边界。

这个排查链路说起来简单，执行起来需要你在架构层面把 trace 日志当成一等公民来设计。agent-native 的调试对象不再是你写的代码，而是模型与环境每一次交互的"快照串"。没有这种全链路回放能力，故障就只能靠猜。

4. 从零搭建 agent-native 项目的落地清单

如果你决定采用 agent-native，我建议按下面的顺序走。这不是从任何框架文档里抄来的，而是我在多个项目中反复调整后觉得最不容易返工的顺序。

4.1 目标声明：先把"成功长什么样"写下来

在写第一个 agent 之前，先回答三个问题：任务的目标是什么？人类授权的边界在哪里？系统必须严格遵守的规则有哪些？三个问题都写成可验证的语句，而不是形容词。

比如"自动处理用户改地址申请"，这是一个不合格的目标声明。合格的写法是：

• 当用户请求修改收货地址时，agent 必须判断订单当前状态。
• 若订单已发货，必须告知用户无法在线修改，并提供转人工按钮。
• 若订单未发货，必须先调用确认工具获得用户对新地址的确认，再执行地址更新。
• 所有地址更新动作必须记录操作日志，日志字段包括用户ID、原地址、新地址、操作时间、会话ID。

这些条件就是需求和测试用例的原型。agent-native 系统的 prompt 写得再好，如果目标声明本身含糊，后面全盘皆输。

另外，目标声明还是 agent 系统 prompt 的基础。我会把前 500 token 固定写成目标和规则区，后面才是动态注入的上下文。这样至少保证每次决策时，模型最先看到的是业务红线。

4.2 工具接口设计：名字、描述、参数要像写对外开放 API 一样严格

工具层是整个 agent-native 架构里最值得花时间打磨的部分。我的工具设计检查清单是这样的：

工具的名字要能直接表达操作结果，动词+名词，避免抽象说法。比如 allocate_coupon 比 coupon_handler 好，revoke_authorization 比 auth_action 好。

工具的 description 必须包含四要素：触发条件、行为、适用场景、边界限制。前面 3.1 的例子已经证明了边界限制的重要性。描述的字数控制在 50 到 150 字之间，太短信息不足，太长模型容易把注意力分散。

参数的 schema 要严格。不要图省事把所有参数都设计成 string，模型会根据你给的 schema 来理解参数语义。能枚举的字段全都用 enum，数字字段设置 minimum 和 maximum，日期字段设定格式。这样就算模型传错了参数，也能在功能调用解析层给出明确的 error message，而不是直接抛进下游服务。

还有一条容易被忽略的点：工具错误信息的返回格式也要设计。agent 拿到工具返回后，需要在接下来的规划里自己调整策略，所以工具的错误信息不能是给人类看的堆栈，而应该是"发生了什么+你可能做错的原因+建议的替代方案"。我们给所有工具错误定义了一个统一结构：code、message、suggestion、request_id。这样模型的自我纠错成功率大幅提升。

4.3 状态管理与图编排的取舍

agent-native 应用有两种典型的状态管理形态：一种是把状态全程放在上下文里，让模型自己管理；另一种是用外部图编排框架（比如 LangGraph 类或自研状态机）维护显式状态，每一步转向由模型决策但状态由框架保存。

我的取舍标准是看任务的决策路径深度。如果任务的正常路径是 3 到 5 步决策，上下文管理足够；如果路径可能达到 8 步以上，或者存在异步等待（比如用户确认超时、外部回调），就必须用外部状态机。

举一个具体场景：用户要办理退款，涉及确认原因、检查订单、计算金额、提交审批、通知用户五个步骤，其中"检查订单"可能因数据不一致需要等待用户补充材料。这个场景中如果状态只存在上下文里，一旦用户隔天再回复，之前的上下文可能早已过期或混入了其他任务。用外部状态机把"等待用户补充"标记为一个挂起状态，agent 下次加载时直接从该状态继续，才是生产级的方案。

同时要记住，外部状态机不是要剥夺模型的决策权，而是负责状态持久化，让模型每次只思考"在当前状态下下一步最合理的动作"。人机协作里的状态管理也是同样逻辑，这对后续接入异步审批流程尤其重要。

4.4 prompt 之外：评估集、回放与灰度策略

最后一个落地清单项是测试体系。你不能等系统上线了才发现模型在某些情况下会绕开护栏，必须在开发期就建立一套评估集。

评估集建议包含三类数据：正常路径用例、边界用例、对抗用例。正常路径用例模拟高频常规操作，边界用例包含缺少关键信息、工具返回异常、用户表达歧义等，对抗用例专门测试模型是否会执行被规则禁止的操作，比如试图绕过审批直接调退款。

评估方式不要只看最终结果对不对，还要看工具调用轨迹是否合理。我会统计几个指标：任务完成率、工具调用成功率、平均迭代轮次、单任务成本、护栏触发次数。这四个指标在开发阶段和上线后都要持续跟踪。

上线策略上我不建议直接全量。先跑影子模式，把真实用户请求同时喂给旧系统和 agent 系统，对比双方的完成率和成本；再挑 5% 流量放给 agent，逐步放大。灰度时的核心监控是护栏触发次数和转人工率，这两项如果异常，立即回滚。这一套流程走下来，agent-native 项目具备基本的生产卫生条件。

5. 什么时候不应该用 agent-native

聊了这么多 agent-native 的优势、架构和实践，最后我想说一个很多人不爱听的结论：agent-native 不是所有问题的答案，甚至多数内部工具不应该以它为主。架构选型要讲最少智能原则——只在你需要的地方引入智能，不要让智能变成默认选项。

5.1 简单直接流程：过度设计的代价

如果你的业务流程固定、规则明确、异常路径少，比如定时导出报表、同步用户资料、发送固定邮件，那用 agent-native 纯粹是给自己找麻烦。这些场景用传统脚本科 30 行代码就能完成，既快又稳定。换成 agent 以后你要支付额外的延迟、token 成本和不可控的中间决策，一切没有变好，只是变贵了。

我做过一次粗略对比：一个固定流程的处理时间从 800 毫秒变成 agent 的 4 到 6 秒，成本从几乎为零变成平均 0.03 美元。换来的收益是零，因为它根本不需要弹性。对一个企业内网批量任务来说，这个代价没有必要。

判断标准其实简单：如果你把流程画成流程图，所有分支都能在画图时列全，那就不需要 agent。agent-native 真正适合的场景是分支无法枚举、决策依赖大量实时信息、用户意图表达高度泛化的地方。

5.2 强合规与强审计场景：必须保留人类审批节点

涉及资金操作、医疗建议、法律意见等强合规场景，即使采用 agent-native 也要保留硬性的审批节点。我见过一种错误做法：让 agent 根据规则直接决定是否发放退款，理由是人在循环里太慢。上线后不久就出现了利用语义变体绕过规则限制的个案。

我的建议是这类场景把 agent 定义为"决策建议者"而非"决策执行者"：agent 收集信息、分析风险、生成建议项，最终动作必须由人类在专属审批界面上确认，且每一步 agent 的推理依据都要留痕。这样既能享受智能体的理解能力，又不丢掉责任链和审计链。

从技术层面，这样的系统仍然是 agent-native 架构，只是工具层多了一个"request_human_approval"工具，这个工具不能被 agent 绕过，也不能被 agent 通过其他工具强行替代。你在设计时要把这个工具当成不可伪造的边界，在代码层做硬编码校验。这是一条不能妥协的安全线。

5.3 混合架构才是常态：给现有系统做一次"体检"

经历了这么多项目后，我个人最推荐的不是全系统 agent-native，而是混合架构：把系统里每个业务流程拿出来体检，标注出哪些步骤是确定性的、哪些是启发式的、哪些是开放式的，然后按三个类型分别用代码、规则引擎和智能体。

体检的维度可以参考这几条：

• 该步骤是否存在唯一正确做法：是，放代码里；否，进入下一步评估。
• 该步骤的输入是否完整且结构化：是，且逻辑简单，用规则引擎；否，考虑 agent。
• 该步骤是否需要理解自然语言、图像或复杂语义：是，用 agent；不需要，别用。
• 该步骤出现问题的影响范围是否可控：影响极小，可让 agent 尝试；影响巨大，必须人工介入。

照这个标准做完体检，你会发现真正需要 agent-native 的往往是系统中一小部分高价值的语义理解与自主决策环节。其他部分继续老老实实运行。这个结论和 "agent-native 应该成为架构默认" 的说法相矛盾，但它是我踩过坑之后最想分享的体会——架构不是为了追新词，而是为了让系统在自己该智能的地方智能，该确定的地方确定。