企业官网建设流程全解析

这两年我陆陆续续经手了不少LLM相关的项目，从最开始聊天机器人Demo，到后来真正跑在业务系统里的生产级Agent，最大的感受就一个字——变。模型答案变来变去，格式变来变去，同一个问题今天能答明天就卡壳。很多人一开始都觉得“哎呀，模型不靠谱，是不是换个更强的模型就行了”，结果换了模型发现该出的问题一个没少，只是错误方式换了个花样。后来我才慢慢摸清楚一个道理：LLM本身就是不确定的，它天生就带随机性，这不是缺陷，这是它的内在属性。想让一个“不确定的引擎”跑出“确定的结果”，靠的不是祈祷模型稳定发挥，而是靠工程手段把不确定性围堵住，在模型外面构建一层确定性。

这篇文章想跟你聊的，就是这个“围堵”的过程。我会把智能体工程里最关键的10个维度一条一条拆开，讲清楚每个维度解决什么问题、背后是什么原理、有哪些实操步骤和踩坑经验。不管你是在做客服Agent、数据分析Agent还是自动化流程Agent，这套框架基本上都能直接套用。文章不会堆术语，能类比的地方我尽量用生活化的方式讲清楚，刚入门的朋友也能跟得上。

1. 先搞明白：LLM的“不确定”到底来自哪

很多新手常犯的一个错误，是把LLM当成传统软件对待——输入固定参数，期望输出固定结果。但LLM本质是一个概率模型，它每次生成token的过程，都是在候选词表上按概率分布做采样。这意味着哪怕温度（temperature）设成0，相同输入也可能因为模型内部的计算精度、并行批次、甚至是同一时刻服务端的微小差异而出现不同输出，更不用说温度调高之后那种明显的“随机发挥”了。

除了采样随机性，还有三个隐藏的不确定性来源容易被忽略：

• 模型版本漂移：模型服务方更新参数、调整系统提示词模板，都会让行为发生变化，可能上一版能稳定输出的JSON格式，这一版就开始夹带解释文字。
• 上下文敏感性：同样的问题，前面多了一段对话历史，或者参考文档的顺序变了，模型的回答方向就可能跑偏。
• 指令遵循的不稳定性：模型并不是每次都能严格遵循你给的约束条件，尤其当约束条件多、彼此还有先后逻辑时，很可能漏掉其中一两条。

这个不确定性，放在聊天场景里问题不大——用户本来就接受闲聊式的回复。但一旦要接生产业务，比如自动下单、自动出报表、自动回复工单，LLM输出就要进流程、入数据库、触发后续动作，这时候哪怕1%的异常率，放到每天百万次调用里就成了一万次事故。

所以智能体工程的第一性原理可以概括成一句话：LLM负责“生成可能性”，工程系统负责“收缩可能性”。把可能性收敛到一个业务可接受的范围内，Agent才是可靠的，否则只是一个会说话的模型壳子。

2. 任务规划：把大问题拆成“看得懂、能检查”的小步骤

2.1 为什么复杂任务必须拆解

早期的Agent设计往往图省事，把一个复杂问题整个丢给模型，让模型“自由发挥”出结果。你会发现这种方式的成功率低得惊人。不是模型不聪明，而是模型的注意力是有限的，上下文越长、任务越复杂，它对关键信息的聚焦率就越低。这就像让人在五分钟内做完五十道混合运算——不是你不会做，而是做到后面精力涣散，错误率飙升。

拆解的价值在于：每步子任务的复杂度降下来了，模型“一次只做一件事”，输出的可控性就高得多。同时，拆解之后每一步的输出结果都可以被独立校验，哪一步错了就重试哪一步，而不是整个流程推倒重来。这种模式，业界叫“任务编排”，本质上跟程序员把大函数拆成小函数是一个道理——单一职责原则。

2.2 规划器的三种实现方式

规划器说白了就是决定“下一步做什么”的组件。按实现复杂度从低到高，大致可以分成三类：

• 固定流程编排：用代码写死步骤序列。比如“先调用意图识别 → 再查询用户信息 → 然后生成回复”。这种方式最稳定、最好排查，适合业务流程非常确定的场景。
• 规则+模型混合规划：用预设规则兜底，规则覆盖不了的分支再让模型决策。比如判断用户问题是否属于可处理范围，可以用关键词+分类模型，真正拿不准的才交给LLM。这个方案的性价比最高，也是最多团队最终落地的形态。
• 纯模型自由规划：让模型自己决定步骤序列，动态调整。听起来很酷，但生产环境里几乎都会被坑——模型规划出来的步骤可能不存在、顺序颠倒、忽略了约束条件，排查成本极高。

我给的建议是：生产级Agent优先用固定流程编排，特殊情况再用模型兜底。不要一开始就上“全自动”的野心方案，先让流程跑稳，再逐步增大模型决策的边界。

2.3 拆解的实操粒度

拆解粒度的问题，既不能太粗也不能太细。太粗，子任务还是复杂，模型处理不动；太细，规划开销和调用成本会成倍上涨。一般来说，一个子任务的描述最好控制在“一条指令内能说完”的程度，并且这个子任务可以对应到一个明确可校验的输出结果。

比如做一个“客户咨询分类与回复Agent”，我不会让它直接“回答用户问题”，而是拆成：

1. 识别用户意图（购买咨询/售后投诉/账户问题）
2. 抽取关键实体（订单号、产品型号、问题描述）
3. 检索相关知识与历史记录
4. 生成草拟回复
5. 校验回复合规性

每一步的输出边界都很清楚——意图是一段枚举值，实体是一个JSON结构，草拟回复是一段文本，合规性校验是布尔值。这样拆分下来，每一步都能单独测试、单独优化，最后再串联成完整链路。

3. 上下文工程：给Agent装上“分得清轻重缓急”的记忆

3.1 上下文窗口不是记忆库

很多人会把“上下文窗口大”误当成“记忆力强”，这是个很关键的认知误区。上下文窗口只是“短期工作台”，模型能在这一小段内容里完成理解与回答，但并不意味着它能把窗口里的每个细节都记住、都用到。窗口中间的信息容易被两头的信息挤掉，这是注意力分布的特性。

生产级Agent需要的，不是无限拉大窗口（那样成本爆炸、响应变慢），而是建立一套分层记忆体系。不同重要程度的信息，存储在不同层级的介质中，在需要时再被检索调用。

3.2 三层记忆架构实操

我的习惯是把记忆分成三层：工作记忆、短期存储、长期存储。

工作记忆就是模型实际看到的Prompt内容，只放本轮任务最需要的信息。比如正在处理一笔订单退款，工作记忆里只需要放订单基本信息、用户诉求、退款规则，而不是把用户三年前的全部聊天记录都塞进去。

短期存储一般是Redis或内存数据库，存当前会话的中间状态，比如对话进行了几步、哪些信息已经确认过。Agent重启后短期存储可以丢失，但运行中的链路状态丢了会导致流程错乱，所以要设计好会话级的恢复机制。

长期存储则是向量数据库或传统数据库，存用户的长期偏好、历史订单、历史结论等等。查询时机是“当前任务需要时”才检索，而不是一股脑全量灌入。长期存储的检索质量，直接决定Agent是不是“懂行”还是“只会瞎聊”。

3.3 上下文裁剪的几个实用技巧

上下文裁剪最大的难点是你没法预判模型到底需要哪些信息。我常用的方案是三层过滤法：

1. 硬性规则过滤：按业务类型、时间范围、字段类型过滤掉明显无关的数据。
2. 相关性召回：对剩余候选内容做向量检索，只保留相似度Top K。
3. 动态组装：先把召回结果按重要程度排序，再拼进Prompt里的不同位置，最重要的放最后（模型对末尾内容注意力最强）。

这套做法配合RAG（检索增强生成）框架非常好用。我见过很多RAG效果不理想的案例，最后排查下来不是向量化模型的问题，而是把太多不相关内容一起塞给了模型，导致模型“注意力稀释”。上下文裁剪做得好，RAG效果能直接上一个档次。

4. 工具调用：如何让Agent“会用工具”而不是“乱用工具”

4.1 Function Calling的本质

Function Calling，也叫工具调用，是LLM自主能力的关键一环。模型通过输出一个结构化的“调用请求”，把“哪个函数、什么参数”讲清楚，然后由程序去真正执行函数，拿到结果后再回传给模型。这个过程里，模型只是“提需求的人”，真正干活的是代码。

这个设计非常巧妙——模型的职责被限定在“理解意图、匹配参数、生成调用描述”，至于函数内部的逻辑是否正确、是否有副作用，完全由程序控制。这也意味着，工具调用可靠性的上限，不取决于模型聪明到能准确用工具，而取决于工具定义得是否清晰，以及调用结果的校验是否严格。

4.2 写好工具描述：模型真的会“逐字阅读”你的文档

工具描述写得好不好，直接影响模型调用准确率。我见过太多团队把工具描述写得含糊笼统，“该函数用于查询信息”这种写法等于没写。模型只能根据寥寥几个词的描述去猜测工具用途，猜错太正常了。

我的经验是，每个工具描述里至少要包含这几样东西：

• 工具用途说明：说清楚这个工具是干什么的，适合什么场景。
• 参数说明：每个参数的名称、类型、取值范围、是否必填，最好附上例子。
• 调用条件：明确哪些情况下才应该调用这个工具，哪些情况下不要调用。
• 返回结果格式：让模型知道调用后会拿到什么，以便组织后续回复。

比如一个查天气的工具，我不会写“获取天气信息”，而是写“根据指定城市获取未来3天的天气预报信息，输入参数城市名必须是中文城市全称，如‘北京市’。返回结果为JSON数组，包含日期、白天天气、夜间天气、气温范围。当用户询问降水概率时需要另调用降水概率接口。”

4.3 工具调用的验证与降级

除了写清楚描述，生产环境必须对工具调用加一道校验层。我见过最典型的事故是：模型把“查询用户A的订单”识别成“查询用户B的订单”，如果系统直接照单执行，就把隐私数据泄露了。所以在执行任何工具之前，要有参数校验器，检查参数是否符合业务约束，比如订单号格式、用户权限范围、必填字段是否齐全。

另外不要假设工具百分百成功。数据库可能连不上、上游接口可能超时、返回数据可能为空。Agent在调用工具失败后如何给用户反馈，也是设计的一部分。我一般会给Agent配一套降级策略：当工具调用失败时，先重试一次；还是失败，就用固定话术告知用户稍后重试，或者转交人工。千万不要让模型自己“编造”工具返回结果——那是生产事故的源头之一。

5. 输出校验：让模型输出“可以被程序验证”

5.1 输出协议化：从“回复文本”到“结构化数据”

LLM最让人头疼的一点是“口无遮拦”，它既会按要求输出结果，也可能输出额外的废话。而生产系统最怕的恰恰是“多余”。解决办法，是让Agent的每一步输出都协议化——定义好结构化格式（JSON、XML、枚举值等），并强制模型按格式输出。

这里有个实操细节：很多模型支持JSON模式或者结构化输出模式，但即使开了，也不能100%保证输出合法。我的习惯是再加一道“修复层”——用一个小的校验函数检查输出是否能被正确解析，解析失败就触发一次带错误信息的重试。让模型看到“你刚才的JSON解析失败，原因是少了一个右括号”，通常它能自己修回来。

5.2 语义校验：格式对了内容也得对

格式校验只是第一关，内容校验更重要。比如让模型输出“退款金额”，可能是合法JSON，但金额写成了负的，或者把100写成了1000。格式层看不出来，业务层必须守得住。

我的做法是给每个关键输出字段配备一张“校验规则表”，用代码实现类型、范围、枚举、正则、业务逻辑的多重校验：

由于大模型输出维度越来越高，这种校验层相当于“质检员”，是Agent输出进入业务系统之前最后的闸门。

6. 状态持久化：Agent必须“记得住自己刚才干了什么”

6.1 无状态接口的局限性

LLM本身是天然无状态的——你发一次请求，它根据你的Prompt生成回复，然后“清空记忆”。但Agent是一个连续运行的流程系统，从用户发起请求到任务完成，中间可能有多个步骤、多次模型调用、多次工具执行，每一步的产物都可能是下一步的输入。如果中间状态丢失，链路就断了。

很多初学Agent的人会犯一个错误：把中间状态全放在一个Python变量里。Demo没问题，一上生产就挂了——多实例部署时请求被路由到不同机器，本地变量根本共享不了；程序重启一次，进行中的流程全部丢失。生产级Agent，必须有独立于模型服务之外的状态存储。

6.2 状态设计的三个层级

我习惯把Agent状态分成三级管理：

• 会话状态：记录用户与Agent的对话上下文、已经完成的步骤、当前等待什么信息。存Redis，按会话ID关联。
• 任务状态：记录一次完整的业务流程走到哪一步了，比如工单流转、审批流程、退款操作。存数据库，事务性操作要能回滚。
• 全局状态：记录系统级配置、模型API信息、开关状态。存配置中心或环境变量，不能跟业务数据混在一起。

各级状态之间要有清晰的关联关系和存储边界。最常见的事故是——会话状态里塞满了不该存的大字段，比如完整的历史对话原文，Redis内存被撑爆；或者全局配置硬编码在代码里，上线改配置需要重新发布。这些坑踩一次就够了。

6.3 状态持久化的序列化选型

序列化格式推荐优先使用JSON，因为可读性好、调试方便。但架构上要注意向前兼容——给状态结构增加version字段，结构变更时做迁移。我在实际中见过不少团队因为状态结构变了，老任务恢复时直接崩掉，原因就是没有处理兼容性。

另外状态恢复是个容易忽略的细节：当Agent异常重启，面对一个进行到一半的任务，它的恢复策略应该是“从最近一个已完成步骤开始重算”，而不是盲目从第0步重跑。这要求每一步的产物被持久化时，同时记录它的生成状态和依赖关系。

7. 可观测性：生产环境必须给Agent装“监控摄像头”

7.1 为什么传统的日志方案不够

普通接口的日志方案是“记录请求和响应”。Agent场景远远不够——一次任务可能产生多次模型调用、多个工具执行、多次状态变更，任何一个环节出问题，都可能导致最终结果偏差。而问题往往不是集中在某一次调用上，而是分布在整条链路的“组合逻辑”里。

所以我一直建议：Agent的可观测性要以“链路追踪”为核心，而不是以“单次调用”为核心。你现在需要的，是能够回答这些问题的监控系统：

• 这个用户的任务，从开始到结束，一共走了哪几步？
• 每一步用了哪个模型、哪个工具、耗时多少？
• 哪一步的输出触发了后续的哪一步？
• 模型返回的内容前后是否发生了反转或异常？
• 一次失败是偶发还是持续性的？

7.2 日志里该记什么

Agent日志的丰富程度，决定了排查问题的效率。我给一个最低要求的清单：

• 每次模型调用的完整输入输出（包括系统提示词、携带的上下文、生成的输出）。
• 工具调用的请求、响应、耗时、错误信息。
• 状态变更记录，哪一步改了哪些字段，旧值是什么新值是什么。
• 耗时的分阶段统计，标注出模型调用时间、工具调用时间、等待时间。
• 上下文构建的快照，重建现场时查看Prompt里实际放了什么材料。

有了这些原始记录，排查“为什么Agent答非所问”“为什么工具没被调用”“为什么某个数据一直查不到”，效率能提升好几倍。

7.3 线上监控的Two-Step法

第一步是指标监控，盯成功率、平均耗时、工具调用失败率、模型解析失败率这些关键指标，设置告警阈值。第二步是详情回溯，当指标异常时，可以从链路追踪系统里拎出具体的失败样本，逐环节查看，定位根因。

很多团队只做了第一步，知道“系统挂了”，但不知道“为什么挂”，这是最尴尬的状态。我建议从一开始就把链路追踪的基础打好，哪怕刚开始简陋一点，只记录关键节点，也比什么都看不清强。

8. 失败恢复：重试不是万能药，降级才是关键

8.1 模型调用失败的分类

模型调用可能因为多种原因失败。网络超时、API限流、内容审核拦截、模型服务端异常、输出格式非法。不同失败原因的应对策略完全不同。如果一律无脑重试，限流场景只会越重试越限流，内容审核场景重试十次也一样被拦。

我的分类方法是：

• 瞬时错误（网络抖动、5xx）→ 指数退避重试，最多3轮。
• 限流错误（429）→ 降低频率，扩大等待时间，或切备用模型渠道。
• 固定错误（参数非法、内容被拦截）→ 不重试，直接进入兜底逻辑。

给Agent加一个统一的“模型调用错误处理中间件”，把这几类错误分类处理，能省掉大量排查成本。

8.2 工具失败的降级策略

工具执行失败的降级设计，我总结了一套“四级降级”思路：

1. 重试：瞬时故障，间隔后重试1-2次。
2. 换路：换个数据源或换种查询方式。比如主库查询失败，切到只读副本；精确匹配失败，换模糊检索。
3. 简化：降低目标质量。比如用户问“明天北京的天气”，完整数据拿不到，就返回“目前暂时无法获取详细预报”并给出常识性的简要说明。
4. 转人：兜底把任务转给人工处理，并在转交材料里附上完整上下文。

这条降级链路的关键是：每一级降级都必须有明确触发条件与降级话术，不能让模型自由发挥生成“安慰用户的话”。AI编的安慰话术，如果信息不准确，反而会激怒用户。

8.3 幂等性设计：重试会不会造成重复扣款

说到重试，就不得不提幂等性。如果Agent的某个工具是“创建订单”“发送邮件”“扣减库存”，重试必须保证不会重复触发。通用的做法是为每次Agent运行生成一个全局唯一的trace_id，工具执行前先检查这个trace_id是否已经处理过，处理过就直接返回上一次的结果。

我就吃过这个亏：有一次给某个自动化流程加了个重试逻辑，结果工具本身没做幂等，重试一次就新增了一条重复工单，最后用户收到了两个相同通知，后台的订单也重复建了两遍。从那之后，凡是涉及写操作的Agent工具，我第一件事就要求接口支持幂等键。

9. 评测体系：没有测评，就没有迭代

9.1 凭感觉调Prompt是最大的坑

“我觉得这样写Prompt效果更好”——这句话我听了太多次，也踩过太多次坑。LLM的行为不仅受当前Prompt影响，还可能受模型版本更新影响，你今天调好的一套东西，过了两周可能就漂了。没有评测体系的Agent项目，就像开一辆没有仪表盘的车，你隐隐觉得哪儿不对劲，但说不清是哪儿不对、影响多大。

9.2 三层评测指标体系

我的习惯是建立三层评测指标：

• 基础质量指标：格式合法率、解析成功率、重试率、超时率。这些指标是硬性门槛，不过关就要做回炉优化。
• 业务效果指标：任务完成率、用户满意度、一次性解决率、工具调用准确率。这些指标直接反映Agent的业务价值。
• 稳定性指标：相同输入多次运行结果的一致性评估、对抗样本鲁棒性。这些指标决定Agent是否能应付真实世界的变化。

每条核心链路至少要建设一套自动回归评测集。每当修改Prompt、切换模型、调整工具参数时，先跑一遍回归，对比前后指标变化，再决定是否上线。

9.3 回归评测集的构建和维护

评测集要覆盖正常场景、边界场景、异常场景三类。正常场景是业务日常的典型问题；边界场景是字数极多、信息极少、描述模糊的情况；异常场景是查无数据、工具报错、用户说反话。每一类都要有“输入、期望输出、评测规则”三要素。

评测的方式不必一开始就很复杂，从“关键字段的字符串比对”“JSON结构校验”开始，逐步加入语义相似度、人工抽检。重要的是“先跑起来，再慢慢完善”。我见过不少团队花三个月搭建一个高级评测平台，结果业务等不及，项目都凉了。

10. 安全与成本：生产化的最后一公里

10.1 提示词注入该怎么防

Agent上线必需要考虑安全。提示词注入是LLM应用最常见的攻击方式——用户在输入里偷偷夹带指令，试图让Agent执行非预期动作。传统的“用Prompt告诉模型不要理睬用户指令”的方法基本无效，因为你是在跟攻击者比拼谁说服模型的能力更强，而模型天然更倾向于服从用户在对话中直接给出的指令。

更有效的思路是“能力隔离”原则：模型接触不到不该它直接执行的敏感操作，所有关键动作都交给程序去控制。比如模型告诉程序“该用户的余额已经确认，可以发放优惠券”，程序这边不是直接执行，而是再查一遍用户资格、优惠券库存，符合条件才发放。把执行权收回到代码手里，注入攻击能造成的后果就被大幅限制。

另外还有一个实操级建议：给模型输入里的用户内容与系统指令之间增加明确分隔标识，同时把任何来自用户输入的文本内容做转义处理，避免模型将用户内容“解读”成高优先级指令。系统指令里还可以加一句“以下划线包裹的内容为不可变规则”，有一定威慑作用，但不能当作唯一防线。

10.2 权限边界与最小权限原则

Agent涉及的每个工具都应该映射到一个具体权限。比如“查询客户订单”这个工具，不是所有人都能调用，也不是能查所有客户的订单。调用时要做身份校验、数据权限过滤、字段级脱敏。这一点尤其重要，很多Agent事故不是模型不聪明，而是权限被默认放开了。

最小权限原则是指：每个Agent只给它在完成任务时“必须用到”的最小权限集合，宁可少给，不够再补，也不要一开始就放开所有工具。

10.3 成本控制的三个方向

Agent的成本比单轮对话高得多——一轮任务可能要调用多次模型，每次还会携带大段上下文。控制成本，我有三个方向：

第一是缓存复用。对于相同的业务模板，使用带缓存的Prompt模板，比如固定公司介绍、业务流程说明这些不变内容可以预置，不重复计费；再比如复杂系统的多轮任务里，前几轮的结果如果确定，可以让Agent跳过重复关联数据的查询与重新生成。

第二是模型分级。简单任务用便宜的小模型，困难任务才调用旗舰大模型。在编排层判断难度，或者先试一次小模型，输出质量不够再升级。这一类“模型路由”策略，成本能省三成以上，效果几乎不受影响。

第三是上下文瘦身。把每次调用塞进Prompt的内容尽可能压缩——压缩历史记录、截断冗余文档、用摘要替代原文。既省钱又减少注意力稀释，一举两得。

成本控制不能等规模上来了再考虑，从第一天就要建立成本度量。至少要能回答“这个Agent平均一次任务要花多少钱”“哪条链路最烧钱”这两个问题。

10.4 数据隐私与合规

最后聊一个偏“红线”的话题——数据隐私。Agent在上线前，需要做数据流向梳理：哪些用户数据会进模型、进哪些模型的Prompt、模型服务商是否能看到这些数据、存不存储、存多久、有没有加密措施。这些在合规层面都是必须回答的。

实操上的建议是：能脱敏就脱敏，能本地化就本地化。把用户手机号、姓名替换成假名或编号，让模型处理时接触不到真实个人信息。敏感字段过滤和最小化是隐私保护的核心，不是等出事才补救，而是要在架构设计阶段就留出脱敏层。

写在最后的一个实操习惯

文章写到这里，10个维度基本都覆盖到了。最后分享一个我个人的习惯——我从做Agent项目开始就坚持“每次改动只动一个变量”：改Prompt的时候不换模型，换模型的时候不改Prompt，调工具参数的时候不动编排逻辑。这样任何指标变化都能明确归因，到底是谁导致的效果波动一目了然。很多人一朝翻车，就是因为同时改了太多东西，出了问题根本不知道是哪一环炸的。

这套方法不是什么高深的学术理论，就是从一次次生产事故和故障排查里踩出来的经验。你如果正在从零搭建自己的生产级Agent，可以先从任务规划、工具调用、输出校验这三个维度入手，把它们做扎实，再逐步补齐状态持久化和可观测性。一步一步来，不要想着一天建完罗马，能稳定跑起来就是胜利。