企业官网建设流程全解析

先说个可能让很多团队都有共鸣的场景：我们上半年做了三个“AI+传统业务”的项目，Demo都跑得飞快，一上生产就全部哑火。客服机器人答非所问、知识库问答动不动就幻觉、审批流套上大模型之后反而没人敢用。复盘时发现病根非常一致——我们把AI当成一个外挂插件，塞进一个根本没为它设计过的旧系统里。后来整个技术方向转向agent-native，也就是从架构层面把智能体当成一等公民来设计，问题才逐渐解开。

这篇文章就把我对agent-native的理解、踩过的坑、以及一套可以复现的最小骨架全部写出来。适合正在从“LLM套壳”往“Agent应用”转型的团队，也适合那些已经跑通概念验证、但不知道下一步怎么接生产环境的开发者。

1. “套壳应用批量死亡”背后，agent-native到底在反对什么

很多团队对Agent的理解停留在“调一下大模型API，多轮对话，再拼几个函数”。这不算错，但远远不够。agent-native要反对的，恰恰是这种“AI套壳”式的堆叠。

1.1 一个客服Bot的失败复盘：问题不在模型不够聪明

我团队做过一个售后客服Bot，最初架构非常简单：用户提问，把问题拼进Prompt，加上一堆历史消息和FAQ片段，让大模型生成回答。刚开始测试集准确率挺可观，上线后却暴露了一连串问题。

客户问“我上周的订单为什么还没发货”，模型回答得头头是道，但是完全没查任何订单数据，因为它根本没有权限也没有工具去查。客户在对话里说“那我退款吧”，模型只会重复“抱歉给您带来不便”，它不知道退款要走哪条审批流，不知道需要冻结库存，也不知道要通知仓储接口。

问题不在模型智力不够，而在系统压根没有给模型提供“行动的接口”。传统架构里，业务逻辑是预编译的，数据模型是围绕人和表单设计的，AI只是最后贴上去的一层“智能皮肤”，模型只能看和说，不能做。这就是典型的非agent-native架构。

1.2 套壳与agent-native的分界：控制权、状态与数据模型

我后来总结出一条分界线：判断一个系统是不是agent-native，不看有没有Chat窗口，而看三件事。

第一，控制权归属。传统架构的控制流是代码写死的，用户点按钮、触发事件、执行对应函数；agent-native的控制流在运行时由模型决策，“下一步做什么”是概率输出，代码只提供选项和护栏。

第二，状态是否一等公民。套壳应用的状态散落在数据库表里、Session里、前端LocalStorage里，Agent要拼拼凑凑才能拿到全貌；agent-native把“AgentState”作为全局唯一的上下文，记忆、目标、工具执行结果、待办任务都写在这一个状态对象里。

第三，数据模型是否围绕Agent设计。套壳应用的数据表是给业务用的，关联关系复杂；agent-native的数据模型要显式建模“记忆切片”“工具调用记录”“子任务状态”“人工干预点”。什么时候该让模型自主，什么时候必须插一脚人工审批，这些在设计数据库时就要定好。

如果这三条一条都不满足，那就算在页面上放一百个AI按钮，它依然是“套壳”，周期一长必然死于不可维护和失控。

2. agent-native的五个承重设计：记忆、工具、规划、状态、反馈

一个能上生产的agent-native应用，我习惯用五层承重墙来拆解：记忆层、工具层、规划层、状态层、反馈层。缺了任何一面墙，系统都能跑，但一定会在某个压力点塌方。

2.1 记忆层：记忆不是聊天记录的堆叠

很多团队把记忆理解成“把历史消息拼进Prompt”，这种做法在上下文短的时候勉强能用，一旦对话轮次超过十轮，Token爆炸、信息稀释、模型开始遗忘关键约束，体验断崖下跌。

真正的记忆分层至少要做三件事：短期工作记忆保存当前任务栈和中间结果；长期事实记忆以结构化方式存储用户偏好、业务实体、历史决策；语义记忆做向量化索引，按需召回。我现在的做法是，把每次有信息量的交互转成一段“记忆切片”，每个切片有类型、时间戳、关联实体和摘要向量，查询时先做相关性召回，再决定塞多少进上下文。

记忆层要解决的不只是“记不记得住”，还有“该忘的能不能忘”。金融场景里客户的敏感信息、审批流里的合规要求，哪些字段允许进Prompt、哪些只能做加密引用，必须在记忆层入口就把过滤做掉，不能指望模型自己管住嘴。

2.2 工具层：把“能力边界”和“权限护栏”画清楚

没有工具链的Agent只能纸上谈兵，工具链设计不好则会变成潘多拉魔盒。工具层有一个我反复踩坑的原则：工具的描述比实现更重要。

模型选工具不靠读源码，靠的是函数名、描述和参数Schema。我见过有人把工具描述写成“查询订单信息”，结果模型分不清该用它还是用另一个“获取物流轨迹”，经常选错。后来我们按“动作+对象+边界”的格式重写描述，比如“查询当前用户最近30天内的订单列表，返回订单号和金额，不包含退款单”。模型选工具的准确率立刻上了一个台阶。

权限护栏也不能放在工具内部再做二次校验，要在工具注册时就给每个工具打上权限标签，比如读、写、审批、外部调用。给Agent绑定最小权限集，运行时任何工具调用都先过一道策略过滤器，不满足就直接拒绝并返回原因。模型哪怕再聪明，也不该拥有它不该有的按钮。

2.3 规划与执行：把控制权交给模型的代价

在agent-native架构里，模型的输出不是最终答案，而是一个行动计划。最传统的做法是让模型直接输出一个JSON数组，里面是步骤列表，再逐步执行；更稳健的做法是“动态规划+迭代执行”，也就是每走一步重看当前状态，再决定下一步，而不是一次规划到底。

动态规划更接近Agent真实工作方式，但代价是失控风险。我经历过Agent为完成一个简单退款任务，反复调用库存查询和订单查询接口，因为每一步都觉得自己信息不够，最后绕了二十多轮才走到退款动作。本质上是因为规划层缺少“终止与收敛”的机制，模型在信息不充分时天然倾向于继续探索，而不是下决断。

所以规划层必须配套两个东西：目标分解的约束（每个子任务必须有明确完成条件和下一步候选动作）和收敛压力（每轮执行后必须压缩状态，清楚标记已确认信息和待确认信息，模型不能对已确认信息反复追问）。

2.4 状态与反馈：这是agent-native和workflow最本质的区别

传统工作流引擎里的状态是图上的节点位置，走完一步就前进一步；agent-native的状态是一个活的、可被模型读写的对象，里面既有当前进度，也有中间产物、决策依据和未完成事项。

我常说，衡量一个系统是不是真agent-native，就看它的状态能不能“暂停”。用户上一个任务做到一半，隔天回来要接着做，系统能不能把进度、已收集的信息、待审批项完整恢复，让Agent无缝续跑。如果不能，那本质上仍是线性脚本，只是把if-else换成了模型输出。

反馈层则解决“Agent做完之后怎么知道自己做对了”。每个动作的反馈不仅是成功或失败，还要包含结构化结果摘要、异常原因和这对当前目标的含义。没有这层反馈，Agent会在同一个错误动作上反复试错，甚至自我脑补一个不存在的成功结果。反馈要即时、明确、可机读，这是Agent闭环的最后一公里。

3. 可复现的最小骨架：我用LangGraph搭建的agent-native项目

讲完理念，说一个能直接抄作业的落地骨架。我当前生产环境用的是LangGraph，底层是Python，状态管理用它的checkpointer机制。这个组合不是唯一答案，但对我们来说是对的答案。

3.1 选型逻辑：为什么不用裸API循环，也不用传统工作流引擎

裸调API多轮循环最大的问题是，状态、历史和工具调用的衔接全靠自己维护，代码越写越像意大利面。传统工作流引擎像Airflow、Temporal，擅长的是确定性调度，但很难让模型在每一步动态决定下一步。

LangGraph胜在把“图结构”和“Agent循环”结合了起来：你定义一个状态类型，节点是函数的集合，边可以是条件边，运行时由模型决定的下一步会被映射到图上。这正好落在agent-native的甜区：既有工作流引擎的持久化和恢复能力，又有模型驱动的动态控制权。

当然LangGraph不是零成本，它有自己的抽象概念要学，Debug和观测工具也比不上成熟的APM。但如果团队已经决定走agent-native路线，这个成本是值得的。

3.2 核心数据模型：AgentState、记忆切片与任务栈

我的项目里最核心的状态类型长这样：

from typing import TypedDict, Annotated, Literal, Optional import operator class Task: id: str name: str status: Literal["pending", "in_progress", "waiting_approval", "done", "failed"] required_info: list[str] collected_info: dict depends_on: list[str] result: Optional[dict] class MemorySlice: slice_id: str type: Literal["fact", "decision", "event", "preference"] summary: str embedding: list[float] timestamp: float access_scope: str # 控制哪些字段能进Prompt class AgentState(TypedDict): user_goal: str current_step: str task_stack: Annotated[list[Task], operator.add] memory: Annotated[list[MemorySlice], operator.add] tool_results: Annotated[list[dict], operator.add] pending_approval: Optional[dict] iteration: int error_stack: Annotated[list[str], operator.add]

这里面有几个细节值得展开。

task_stack我用累加器而不是直接覆盖，是为了让每一步的工具调用都形成审计轨迹，后续排查“Agent为什么走到这一步”时可以直接回溯。iteration是全局计数器，它是死循环治理的第一道闸门。pending_approval字段的存在意味着状态模型在设计时就预留了“人类介入槽位”，而不是事后打补丁。

记忆切片的核心不是存原文，而是存“摘要+向量+权限标签”。对话原文可以归档到大存储，真正流入上下文的只有切片摘要。这样既控制Token数，也避免把敏感原文无意识传给模型。

3.3 三个关键机制：循环刹车、工具注册、人工审批挂起

循环刹车我做了两层。第一层是硬性最大步数，比如单任务最多执行30轮，超过就强制转入人工；第二层是语义去重，把每轮的目标摘要和工具结果做一个向量哈希，如果发现连续多轮都是在重复同一意图、只换了表述，就判定为“原地打转”，主动触犯终止条件并请求人工指示。

def should_continue(state: AgentState) -> Literal["agent", "approval", "human", "end"]: if state["iteration"] >= MAX_ITER: return "human" if state["pending_approval"]: return "approval" if has_converged(state): return "end" if is_loop_detected(state): return "human" return "agent"

工具注册我这里用装饰器加Schema声明，让每个工具在注册时带上权限、描述、参数模型：

@register_tool( name="query_order", description="查询当前用户最近30天内的订单列表，返回订单号和金额，不包含退款单", permissions=["read:order"], params=QueryOrderParams ) def query_order(params: QueryOrderParams) -> dict: ...

人工审批挂起是agent-native和普通Agent循环最不一样的地方。当Agent判断某个动作“要做但没权限确认”时，它把动作信息写入pending_approval，然后图执行停在approval节点。审批人通过接口确认或驳回后，状态被更新，图从暂停处继续跑。这个机制让Agent可以在高风险场景下保持自主，但关键节点上仍旧“人在回路”。

4. 运行时才会暴露的硬问题：状态撕裂、死循环与成本黑洞

这些坑没有一个能在Demo阶段暴露出来，全都要等真实用户和真实流量进来后才出现。我分三个最常见的问题讲，每个背后都有一次真实的头皮发麻时刻。

4.1 状态撕裂：AgentState在分布式环境下的同步难题

第一次上生产时我们把单机进程跑成了多副本，然后噩梦来了：同一个用户的会话请求被负载均衡分发到不同实例，A实例更新了状态，B实例还在用自己的旧快照，Agent同一句话在两台机器上产出完全不同的决策。

LangGraph的checkpointer默认是把状态存内存或本地盘，多副本部署下等于每个副本各持一份状态，互相看不见。解决方式是改用分布式的检查点存储，把每个线程ID对应的状态写入Postgres或Redis。

但这里有个反直觉的坑：不能每步都写全量状态。Agent一步的中间产物可能很大，全量持久化很快把数据库拖垮。我目前的方案是“分层持久化”——核心状态字段每步实时写，完整上下文和工具结果走旁路异步刷到对象存储，用事件总线通知其他实例从存储拉取。代价是状态有秒级延迟，但对绝大多数Agent任务足够了。

4.2 死循环治理：最大步数只是兜底，语义去重才是关键

我前面写过用iteration做硬性闸门，但只靠它是远远不够的。真实案例里Agent可以在28轮里换出十二种不同说法表达“我需要确认订单价格”，每一句看起来都在往前推进，实则原地打转。最大步数只能防止无限消耗，却不能识别“正在浪费”。

语义去重是更聪明的刹车。具体做法是给每一步生成一个“意图指纹”，把当前目标、上一步动作、最近一次工具返回摘要拼起来算向量，然后在滑动窗口里做相似度比较。连续五步里有三步相似度超过阈值，就说明Agent在同一个信息点上反复横跳。这时候不要硬着头皮再让它跑，直接转人工，让人类补一条指令或给一个直答。

这个检测逻辑通常还要配合一个“最小信息满足度”判断。每个Task定义时带上required_info，每轮结束后自动检查所需信息是否已经集齐，集齐了就强制终止探索，直接进入决策或执行阶段。我测过这个方案，能让一个原本要跑19轮的订单处理任务压到6轮以内。

4.3 成本与安全：一次真实的事故复盘

有次测试一个售后Agent，预算规划是每天一千个任务，按每个任务二十步、每步一万五千Token估算，大概要消耗三亿Token，已经不少了。结果上线当天下午，链路里一个小工具连续返回异常入参，Agent一遍遍用不同调用姿势尝试纠正，配合上多个并行任务同时涌进来，单小时Token消耗飙到了预算的六倍。

那次事故逼我们做了三件事。第一，全局预算熔断器：按用户、按任务、按小时三个维度设置Token消耗上限，超出即降级为只读模式和人工接管。

第二，把“工具异常重试策略”从“换个说法再试”改成“先归因再决定”。如果错误信息显示入参校验失败，Agent可以调整参数再试一次；如果是远端服务5xx，立刻停止重试并转入降级分支。归因规则写死在反馈层，不再让模型自由发挥。

第三，有权限敏感动作的工具，调用前强制走审批节点，并限制单任务内高危动作次数。这样即便Agent抽风，杀伤范围也有限。

成本控制不是事后算账，要在架构里内建度量。每个状态转移、每次工具调用、每轮模型输出，都要打上标签和成本估算。没有这些数据，你是没有办法在事故发生前做预警的。

5. agent-native不是银弹：反模式与使用边界

理念很好、架构很正，但我不建议任何场景都硬上agent-native，甚至可以说有一大类业务根本不该上。这里讲几个我亲手拆过的反模式。

5.1 三个反模式

第一个反模式是把规则流程硬塞给Agent。有些团队明明业务路径只有三条直线，却非要让模型做“自主规划”，结果模型在三条直线之间反复横跳，把稳定的业务搞出了随机性。业务稳定、分支有限、判定条件明确的时候，老老实实用硬编码流程，比塞给Agent强一百倍。

第二个反模式是过度自主。我看到过有团队让Agent直接操作生产订单库，美其名曰“Agent能自主完成售后全流程”，结果一次模型误判让系统发起了一千多张错误退款单。Agent的自主权必须与它的可修复能力匹配。如果你没有完善的审计、回滚和熔断机制，那就自觉把自主权降到最低。

第三个反模式是记忆滥用。把能塞的全部塞进长期记忆，不仅Token成本爆炸，还会让模型“记仇”式决策——被一些偏远的历史事件带偏当前高优任务。记忆不是越多越好，而是越相关越好，召回的精排逻辑比存储容量更值得投入。

5.2 直线流程用Workflow，发散探索才用Agent

我现在的选型判断其实非常简单：任务的开放度和探索密度决定架构。

售后退款、订单改签、商品分类审核这类任务，核心链路固定，偶尔有边界情况，用Workflow加少量Agent补充即可。Workflow的好处是路径可控、成本稳定、审计容易，每一步是什么、花多少钱全部可预期。

数据分析、研究综述、复杂排障、个性化方案生成这类任务，开放度极高，答案路径没有标准解，强制用Workflow会把Agent的探索能力砍废。这种场景才是agent-native的主场，让模型自己读状态、选工具、定节奏。

最怕的是中间态模糊的团队，自己都说不清做的是流程还是探索，看到热点就上Agent，结果两头不讨好。

5.3 agent-native落地的四个验证清单

我在项目转agent-native架构后，每次评估新业务，会用四个验证项卡一下。

第一，能不能把业务核心状态显式建模？如果你说不清Agent跑一次任务需要的所有上下文，建议先回炉做数据梳理，不要直接开始写代码。

第二，有没有明确的人机边界？哪些动作允许自主、哪些必须审批，要能写出一条计算机规则，而不只是产品经理的一句“高风险要人工”。

第三，出错了怎么收场？工具调用失败、模型判断失误、任务半途而废，分别是什么回退路径。回退方案要提前设计进状态图，而不是等事故发生后靠运维上去救火。

第四，可观测性做没做到位？每个决策点有没有日志、状态快照、Token消耗记录、成本预估。如果答不上来这些数据从哪来，那生产环境会给你上最贵的一课。

最后说一个我个人的判断标准，它比任何架构图都好用：如果你的产品里AI只是“回答问题的人”，你就用套壳方案；如果你的产品里AI是“承担任务并要对结果负责的人”，那请认真考虑agent-native。整个团队的工程重心会从“写接口”转移到“写状态、画边界、建设护栏”，这种转移很痛苦，但也是一条真正能把大模型变成产品的路。