企业官网建设流程全解析

项目上线前的一次内部评审会，业务方追着我问得最多的不是"Agent流程怎么设计"，而是"token会不会把预算烧穿"。我理解这种焦虑，大模型按token计费的模式，让Agent这种"一次任务要跑很多步"的东西看起来像个深不见底的漏斗。但等我们把几个Agent场景真正推到生产环境，累计跑了几百万次调用之后，回看整个过程，最让团队熬夜加班的，没有一次是因为token账单。真正折磨人的，是状态错乱、流程黑盒和结果没法验收。这篇文章就把这三件事掰开揉碎聊透，如果你正准备把Agent从Demo推向生产，或者已经被Agent的各种幺蛾子搞得焦头烂额，这篇文章应该能帮你少走不少弯路。

1. 先聊聊为什么大家对token这么敏感

1.1 token是一笔看得见、算得清的账

很多人一上来就关注token，不是没有道理的，因为它是一笔看得见、算得清的账。一个复杂的Agent任务，本质上是多次大模型调用的叠加：意图识别来一次、信息抽取来一次、决定调用哪个工具来一次、工具返回后再总结一次。每次调用又都包含系统提示词、历史对话、工具描述、工具返回内容和模型输出。

我习惯用实际数字说话。假设一个售后客服Agent处理一次退款申请：先做一次意图识别，假设消耗了2000 token；再做一次订单信息抽取，消耗了3000 token；然后做一次工具调用决策，把工具列表和参数说明全部塞进去，消耗了6000 token；最后生成面向用户的回复，消耗了1500 token。这一趟下来，单任务消耗大概在1.2万到1.5万 token。如果一天有1万用户触发这个任务，日消耗量就是1.2亿到1.5亿 token。按主流大模型服务商的计费标准粗略估算，一天的成本可能是几千块钱的量级。对于很多中小企业来说，这个数字足以让财务部门坐不住了。

这还只是正常路径。更让团队焦虑的是"失控感"：一个Agent如果在某个环节陷入循环，反复调用同一个工具，或者因为解析失败不断重试，token消耗会在几分钟内翻倍。我见过一个数据查询Agent出了故障，因为没有设置单任务上限，一个任务跑了将近两小时，消耗了几十万token。这种"跑飞"的场景一旦出现，大家的第一反应就是把预算看紧，于是一大堆成本控制手段被提上日程。

1.2 token问题其实有成熟的工程解法

token问题看起来吓人，但它有个特点：它是显性的、可量化的，而且工程上有一堆成熟解法可以套用。

第一招是模型分级。不是所有步骤都需要用最强的大模型。意图识别、实体抽取这类相对机械的任务，完全可以用轻量级模型来做；只有最后的复杂推理、长文本生成才需要上大模型。我们实测，用轻量模型处理前两步，单任务token消耗能降40%左右。

第二招是上下文裁剪。很多人习惯把对话历史一股脑全塞给模型，但实际上大模型对超过一定长度后的历史并不敏感。把系统提示词精简、把历史对话截断到最近几轮、把工具返回的大段结果压缩成摘要，这些都直接能省token。

第三招是缓存。同一套系统提示词、工具定义的公共前缀，在大模型服务商支持缓存的情况下，能省掉相当大一部分重复计费。过去机器学习圈有句老话叫"你的模型有多好，取决于你的数据有多好"，放到这里就是"你的Agent省不省钱，取决于你把上下文安排得有多干净"。

这几招都不需要动太大的工程架构，成本模型也是可以提前算出来的。但有个反直觉的情况：当你真的把token压下来了，Agent开始能自由地跑更长链路了，真正难管的问题才浮出水面。我认识一个团队，因为带着极强的token焦虑，设计了一套特别激进的省token策略：每轮只保留用户最近一条消息，历史信息全靠模型生成摘要。结果Agent在第6轮之后开始"失忆"，用户明明说了三次要改收货地址，它每次都重新问地址。省了成本，丢了正确性，最后业务方直接叫停。这个故事告诉我们，token只是表层，它掩盖着更深的工程问题。

2. 真正难管的第一关：Agent的状态一致性

2.1 Agent从"无状态接口"变成了"有状态流程"

传统的单次大模型调用，本质上是一个无状态接口：你输入一段文本，模型返回一段文本，输入和输出之间没有必然的"过程"。但Agent不是这样。Agent是"推理—行动—观察"的循环：它先理解目标，然后决定调用什么工具，拿到工具返回结果后再决定下一步，直到最终完成任务。

这个所谓"有状态流程"，带来的问题比想象中复杂。一个Agent在运行过程中，需要记住的有：用户的最终目标、已经完成哪些子步骤、中间产生过哪些变量、某个工具返回过什么结果、分支条件走到了哪一条。这些状态如果只是散落在对话历史里，就会出问题。

我给你举个实际例子。电商后台有个工单处理Agent，它的任务是帮客服人员处理用户投诉。其中一个场景：用户表示"收到的商品有问题，想退款，但不想承担退货邮费"。Agent需要先判断责任方，再决定是全额退款还是部分退款，然后调起退款流程。这个任务拆开看每一步都不难，但问题在于：用户的原始意图是"不承担运费"，这个关键约束只出现在第一轮对话里。随着Agent和用户继续确认商品问题、核对订单信息，如果这个约束没有以某种形式持续存在，模型在后续决策中很容易忘掉它，最后生成一个"用户承担运费"的方案。

这种问题不是模型能力不够，而是状态管理没做好。在分布式系统里，我们很早就知道"无状态服务更容易扩展、有状态服务要谨慎设计"，Agent把这个问题原封不动地带回来了。

2.2 上下文漂移：token背后最隐蔽的坑

进入生产环境之后，我遇到过一类特别隐蔽的问题，我管它叫"上下文漂移"。这个问题的本质是：随着Agent循环轮次增加，上下文越来越长，早期的关键信息被后来的大量信息稀释了。大模型本身对早期内容、中间内容的注意力权重是不够均匀的，尤其当对话中间插入了大量工具返回内容、思考过程之后，早期的核心约束很容易被"淹没"。

举一个真实的场景。某供应链调度Agent，用户一开始明确说"这批货优先考虑成本，时效可以放宽"。然后在执行过程中，用户连续追问了十几个关于运输路线、车辆类型的技术细节。到最终决策时，Agent居然推荐了一个时效最好但价格贵30%的方案。回看trace日志才发现，最开始那句"优先考虑成本"早就被十几轮对话挤到了边缘位置，模型在做最终决策时，注意力几乎全部放在了最近几轮的细节讨论上。

这里有个很坑的地方：遇到这种情况，业务方第一反应是"大模型不行"，于是大家开始调prompt，把"请记住用户最开始说的优先级"这种话写进系统提示词里。但实测下来，这类"软约束"在长链路场景下作用有限，因为这不是模型听不听得懂指令的问题，而是长上下文下的注意力分配问题。你可以在测试集上验证：用同一个prompt，把关键约束放在第1轮和放在最近1轮，最终决策的正确率差距能到10个百分点以上。

2.3 状态管理到底怎么落地

我在这个环节吃过的亏最多，总结下来有四个可以落地的做法。

第一，把关键状态从原始对话中剥离出来，维护一份结构化的状态视图。不要指望大模型每次都能从一堆历史消息里准确回忆起"用户要求不承担运费"，我们定期把对话历史中的关键信息抽取成结构化字段，比如refund_type、shipping_fee_responsibility，在后续每一轮调用时，把这份结构化状态附加到最新一轮的输入前面，而不是简单地把历史消息全部倒给模型。这样做的原理很简单：结构化状态是明确键值对，模型不需要"回忆"，只需要"读取"。

第二，对高风险流程采用显式状态机约束。Agent的自由度不是越高越好。如果某个环节只有三种选择——继续、终止、转人工，那就不要靠模型自由发挥，直接在流程代码里做判断。让大模型只做它擅长的事：理解自然语言、抽取信息、生成表达；而让代码去做可控的事：状态流转、条件判断、异常处理。这也是很多成熟的Agent工作流框架的核心思路。

第三，对话历史要主动压缩，不要被动截断。被动截断是"从前面把最老的消息丢掉"，看起来省token，实际上把可能还有用的信息丢了。更好的做法是，每执行完一个子任务，就用模型生成一段摘要summary，同时把已经落地的结构化字段同步更新。这样后续轮次的输入变成"最新消息 + 历史摘要 + 结构化状态"，信息密度比完整历史高得多。我实测过，这种做法既能降低token消耗，还能明显提升长任务的成功率。

第四，隔离子任务上下文。一条复杂的任务链里，可能包含多个子任务，比如"先查订单，再查物流，再核算退款金额"。如果这些子任务的所有历史都堆在同一个上下文里，相互干扰是必然的。把每个子任务放在独立的上下文中执行，只在必要时传递结构化输出，能有效避免上下文污染。

3. 真正难管的第二关：可观测性与调试

3.1 为什么Agent黑盒比单次模型调用黑盒更可怕

单次大模型调用出了问题，你看一眼输入和输出，基本就能判断是prompt写得不够好，还是模型理解偏了。但Agent不一样，它是一个多步骤的闭环系统，一个最终错误结果的产生，可能是决策错了、参数传错了、解析失败了、工具返回脏数据了、流程死循环了，甚至可能是模型输出了不符合结构要求的JSON导致校验失败。

我印象最深的一次故障排查。一个企业内部的数据分析Agent，用户问"帮我统计上个月各区域销售额对比"，Agent最终返回了一个完全错误的数据表。业务方非常不满，质问"明明是这么简单一个查询，为什么结果不对"。我们排查了很久，最后定位到问题根源：Agent在第一步意图识别环节，正确识别了"销售额统计"的意图；在第二步信息抽取环节，把"上个月"错误解析成了上上个月；后面所有步骤都在这个错误参数上继续执行。每一步看起来都很正常，但最终结果就是错的。这就是Agent黑盒的可怕之处——没有一个环节"看起来明显有问题"，但整个链路的结果是错的。

更麻烦的是，Agent流程往往很脆。单次模型调用的失败率可能只有1%，但一个五步的Agent链路，如果每一步的失败率都是1%，端到端的成功率大约是99%的5次方，约等于95.1%。换句话说，5%的任务会以某种形式出错。如果每天有1万次任务，就意味着500次任务是有问题的。这500次任务是无法靠"事后看一眼日志"来解决的。

3.2 Agent全链路可观测性怎么建设

要解决黑盒问题，必须有全链路可观测性。我们内部建设了一套Agent执行的trace追踪体系，每条执行记录包含：会话ID、步骤序号、每一步的输入输出、调用的大模型版本、prompt版本、消耗的token数和耗时、返回给用户的最终结论。

这套体系非常管用。业务方反馈"这个用户退款没到账"，我们可以直接定位到该会话的完整执行轨迹：那一步工具调用返回了成功，但那一步读取的订单金额是旧版本数据库里的存量金额。顺着trace，问题根源暴露得非常快。

这里有个经验：除了正向的trace记录，建议对每一步记录"决策理由"。很多Agent框架支持输出模型思考过程，把这部分一并存档，对后续排查极有帮助。有一次我们发现某个Agent频繁选错工具，但看输入输出都正常，后来对比多份决策理由才发现，是工具描述里某个功能的措辞产生了歧义，模型把"新建"理解成了"修改"。

还有几个环节值得记录：每次重试、每次解析失败、每次触发兜底逻辑，都要单独打点。这些看似异常的事件，往往才是衡量Agent健康度的真正指标，而不是单纯的白屏率和请求成功率。

3.3 调试Agent和调试代码是两回事

传统软件开发里，代码出问题了可以在本地打断点、单步执行，定位到具体一行。但Agent本质是概率性的，你不可能说"这里一定会出错"。这导致调试Agent的方式也要变。

我的经验是搭一个离线回放环境：把生产环境记录下来的失败trace输入导出，在本地用一个固定的测试账号，用相同的模型版本、相同的prompt版本重新执行一遍，观察它在哪一步开始偏离预期。这样反复调整prompt或者工具定义，再回放对比。回放调整得足够多之后，才能形成"这样改了会有效果"的直觉。

有个细节需要注意:生产环境的trace里，模型输出和工具返回序列是完整记录下来的。做离线回放时，不要真去调用外部工具服务，直接用录制的工具返回拦截替换，这样才能保证整个回放过程是确定的、可复现的。否则你每回放一次，外部系统返回的数据可能都不一样，问题就被掩盖了。

4. 真正难管的第三关：评估闭环

4.1 没有评估体系，Agent就无法迭代

传统软件改代码，有单元测试、集成测试兜底，改了东西之后跑一遍测试就知道有没有改崩。但Agent改prompt，怎么知道是变好了还是变坏了？这是我们在Agent工程化过程中最头疼的问题，没有之一。

我见过太多团队的做法是"感觉不行就调，调完看一两个例子，感觉还可以就上"。这是发布事故的温床。因为大模型输出是概率性的，同一个prompt换一个用户、换一种问法，结果可能完全不同。仅凭两三个测试用例，根本覆盖不了真实场景的多样性。

正确的做法是建评测集。评测集不是简单找几十条用户问题扔进去，而要包括三个层次：第一层次是标准场景覆盖，就是日常最高频的那批任务类型，每条都要有明确的正确答案或验收标准；第二层次是边界场景，用户表达含糊、信息不全、需求冲突等情况；第三层次是对抗场景，专门测试Agent会不会被诱导偏离流程、会不会输出敏感内容。我当时的做法是先建一个50条规模的评测集，每天模型或prompt有更新时跑一遍，后来又逐渐扩充到200多条，基本能做到"只要这200多条不崩，线上就不会出大事故"。

评测里有个重要问题：怎么判断Agent的输出对不对。如果任务有明确的结构化结果，比如订单状态是否更新、退款金额是否正确，可以直接用规则判断；如果任务是开放式回答，就要引入模型评测员（LLM-as-Judge），由一个大模型来给输出质量打分。但这里有一个坑，模型评测员本身也有偏好，同一个输出换一个评测模型结果可能不同。我的做法是"规则硬指标 + 模型评测 + 人工抽检"三结合。规则判断结果正确性，模型评测判断回答质量，人工抽检覆盖所有评测集的5%到10%，确保整个机制不会跑偏。

4.2 回归测试与灰度发布是生产环境的最后防线

有了评测集，还需要把它纳入发布流程。我们内部每改一次prompt、每调一次工具定义、每发布一次新流程，都强制跑全量评测集，对比改动前后各指标的变化。这块列的指标通常包括：任务成功率、工具调用准确率、无效回复率、平均对话轮数、平均token消耗、人工介入率。

这里面"平均对话轮数"和"平均token消耗"是两个容易被忽略的指标。你可能会觉得token是成本指标，但结合上下文看，平均轮数上升往往意味着Agent在绕圈子，可能是有状态丢失或者决策不果断。这些指标异常通常先于用户投诉出现，是很好的预警信号。

灰度发布同样重要。Agent这种系统，改动一个prompt可能影响所有场景。所以哪怕全量评测集过了，也不能直接全量上。按流量切分，先放5%用户，观察关键指标24小时，没问题再逐步放量。我们在某个内容分类场景就这么做过一次，评测集全绿，但灰度到10%的时候发现某类图片的分类准确率掉了一截，细查是工具返回被压缩后丢了关键字段。这种问题只有在真实流量下才会暴露。

4.3 "端到端成功率"是最应该盯住的指标

我见过很多人汇报Agent项目进展时，喜欢说"模型在XX测试集上准确率99%"。但我要提醒的是，单点准确率不等于任务成功率。原因前面讲过，链路越长，错误率积累越严重。模型单步99%准确率，一条五步的任务链路，端到端成功率大约在95%左右，如果每一步是97%，五步下来只有86%。

我在几个Agent项目里的实测情况确实如此。曾经有个售前客服Agent，单步工具调用选型准确率大概在97%左右，但因为它经常需要连续调用3到5个工具才能完成一个客户询价流程，端到端成功率一度只有82%左右。后来我们做了两件事：一是优化状态管理，减少无效步骤；二是在一些高确定性节点上，把模型决策改成规则判断。端到端成功率最终稳定在93%以上。有意思的是，端到端成功率提上来之后，token消耗也跟着下降了——因为Agent不再因为犯错而重复执行子任务了。这正好呼应标题那句话：token不是管不好的问题，它是"管好状态、管好流程之后自然下降的副产品"。

5. 常见问题与排查技巧速查

5.1 高频问题的排查速查表

调试Agent这段时间，我遇到的高频问题其实集中在几个固定类型上。我整理成一个速查表，遇到类似症状可以直接对号入座。

5.2 几个容易被忽视的细节

除了上表的内容，还有几个容易踩的细节，值得单独提醒。

第一，提示词不是越长越好。很多人为了让Agent表现稳定，喜欢把系统提示词写到几千字，把各种约束、偏好、边界条件全塞进去。但系统提示词太长，反而会干扰模型对当前任务的理解。我在一个项目里做过对照实验，把系统提示词从1500字精简到600字，任务成功率反而提升了3个百分点。原因很简单：关键约束被突出，噪声减少，模型的注意力更聚焦。

第二，工具描述是隐性token，也是隐性稳定性来源。工具描述往往被包含在每次调用的上下文中，这部分token看起来不多，但工具描述写得含糊，会导致模型错误调用工具，进而引发一系列连锁错误。好的工具描述应该包含：这个工具是做什么的、什么时候用、参数定义、常见边界情况、返回结构的说明。把工具描述当接口文档来写，不要当简介来写。

第三，不要把多个任务塞进同一个上下文。有些团队为了省token，让一个Agent会话同时处理用户的多个诉求，比如既改地址又查退款。这样做的风险在于，两个任务的状态会互相污染。我的建议是严格做到"一个Agent实例一次只处理一个核心任务"，必要时启动子Agent，各自维护独立上下文。

第四，从第一行trace开始设计方案。可观测性不是一个发布之后再补的模块，而应该在Agent架构设计时就内置。我们开发流程里规定，所有新开发的Agent执行节点，必须同步设计节点日志、输入输出字段和错误处理打点，否则不能进测试环境。这一步对后面排查问题的帮助，怎么强调都不过分。

写在最后

回到标题那句话。Agent真正难管的，确实不是token。token是显性指标，有明确的优化工具和优化路径，只要你想省，总能省下来。但状态一致性、可观测性、评估闭环这三件事，没有一个是靠"设置一个上限、调一个参数"就能解决的，它们需要在架构设计、开发流程、发布规范多个层面持续投入。

就我个人体会而言，如果一个团队能从第一天就把"状态怎么维护、链路怎么追踪、效果怎么评估"这三问想清楚，Agent项目的推进速度反而会快很多。因为这些工作本质上是在建立工程底线，有了底线，你才敢放开手让Agent去跑更复杂的任务；反过来说，如果一直停留在"调prompt省钱"的表层，那后面每一个新场景上线，都会是一场耗时耗力的救火行动。

真到了生产环境，你会慢慢发现一个奇妙的现象：当状态管理、可观测性、评估闭环都搭好了，token成本反而会降下来。原因不复杂，Agent不再犯那些低级错误，自然就不再需要为错误买单。把该管好的东西管好，成本是水到渠成的结果。