企业官网建设流程全解析

这周我们没有发大版本，也没有谁把哪个模型一夜train爆，但周五下午项目复盘的时候，我在白板上写了三句话：更少 token、更强模型、更难管的 agent。细看下来，这三句话其实是一件事的三个侧面——我们花在 token 上的钱少了，不是因为抠门，而是因为把问题结构想清楚了；模型确实变强了，但强到我们不得不重新评估每个任务的归属；agent 开始扛真实业务了，也第一次让我们真正意识到什么叫“管不住”。

这篇文章就当一次周观感记录，把我这一周在 AI 工程里看到、做到、踩到的东西拆开聊聊。适合正在做 AI 应用落地、尤其是 team 里已经有 agent 相关代码的人看，也适合那些准备把 agent 从 demo 推上生产的同学做个参考。

1. 周复盘的三个关键词：token、模型、agent 的此消彼长

先说说这一周我们团队到底做了什么，不然后面的讨论都是空中楼阁。项目本身是一个偏业务侧的 AI 应用，包含了信息抽取、分析总结，还有两个 agent 在工作流里跑。这周大多数时间花在了三件事上：给线上调用做 prompt 精简和上下文瘦身；把几个简单任务从大模型降级到小模型或规则；给 agent 补日志、补超时、补评估集。

三件事看着互不相干，但周五复盘时数据放在一起，趋势就很明显了。

先看 token。我们七月份的日均 token 消耗和这周比，大概下降了 47%。这不是靠限制用户用量压出来的，而是在相同业务量的前提下实现的。为什么能降这么多？因为做过上下文工程之后，每次请求携带的内容变短了，加上部分任务改走轻量模型，单位请求的 token 数降了不止一个量级。之前一个分析类接口动不动就是 6k 到 8k 的输入 token，现在普遍压到 2k 以内。不是模型变强了让 token 变少，而是工程手段让模型不再被迫处理那么多无关上下文。

再看模型。这周我们内部评测了三个新出的开源模型和一个闭源 API 的更新版本，结论是：在代码理解和格式遵循上，真的是肉眼可见地变强了。之前一个模型要写四五条示例才肯乖乖输出 JSON，现在一条示例加一段 schema 描述就能稳定跟从。但我们没急着把线上全切过去，原因后面说。

最后是 agent。我们有两个 agent 在真实业务流程里跑，一个做资料收集和摘要，一个做多步任务拆解。这周它们分别出了事：一个在同一个知识点上反复调用搜索工具，烧了将近 10 万 token；另一个因为提示词里的目标写得太宽泛，开始把“分析数据”理解成“从所有历史对话里翻找无关信息”，把一个查询任务跑成了全库扫描。管不住的体验，这周算是实打实领教了。

所以这周的观感可以浓缩成一句：token 的账越来越清楚，模型的账越来越友好，agent 的账一塌煳涂。而这三个账其实是关联的，模型越强，agent 越容易“自由发挥”，token 就越容易被浪费；反过来，token 控制得好，往往是因为任务边界设计得好、agent 被约束得死。所以后面我会沿着这三条线，把细节展开。

2. “更少 token”不是省出来的，是结构决定的

2.1 上下文工程：提问方式才是最大的 token 消耗点

很多团队谈 token 成本的时候，第一反应是“换更便宜的模型”或者“砍调用次数”，但我们的经验是，最大的浪费通常藏在 prompt 里。具体说，是藏在那些“每轮都被塞进去、但大部分时候根本用不到”的上下文里。

在这周之前，我们有个接口调的是长文档分析，做法很粗暴：把整份文档塞进 context，再让模型输出结论。文档平均 60 页，塞进去接近 80k token，响应时间 3 秒多，单次调用的成本肉眼可见。后来我们把流程改成：先做章节切割和向量化，命中 top 5 相关段落，只把这几个段落拼进 prompt。输入 token 从 80k 掉到 4.5k，响应时间降到 0.9 秒，而在人工抽检里，答案质量没有明显下降——因为对模型来说，被噪声包围的正确信息和干干净净的正确信息，处理难度完全不同。

这里有个容易被忽略的细节：检索的质量比检索的召回率更重要。我们第一版做了 top 20 召回，想着“宁可多一些也别漏”，结果 token 是省了，但幻觉也回来了——因为塞进去的很多段落是“相关但无用”的，模型会被这些半相关的信息带偏。后来改成 top 5 加一个得分阈值，低于阈值的宁愿不塞，让模型直接说“资料不足”，效果反而更稳。

所以省 token 的第一原则其实是：先别急着换模型，把你的 prompt 拿到 token 计数器里过一遍，问自己——这段上下文对这个任务的贡献是什么？如果每十次调用里只有两三次用得到，那这块肉就该割掉。

2.2 小模型路由与输出压缩：把 token 花在值得的地方

第二个动作是任务路由。以前团队里有个倾向：不管什么任务，都用同一个旗舰模型跑，原因倒也简单——省心。但业务量上来之后你会发现，大量请求根本不需要那么强的推理能力。我们这周做了一个很粗糙但有效的分流：把意图分类、实体抽取、短文本标题生成这类任务，从大模型切到一个 7B 级别的开源模型上跑。

切换之前我是有一点担心的，7B 模型在复杂推理上确实不行，但这类任务恰恰不需要复杂推理，它们需要的是“稳定地按照格式输出”。我们用 200 条带标注的样本做了回归评测，准确率跟大模型差距在 1.5% 以内，但 token 成本直接降了一个量级，延迟也低了将近一半。大模型的调用量降下来以后，真正的复杂推理任务切换到更贵的模型也不心疼了。

输出压缩同样有效。以前我们让模型直接输出大段分析文字，再在代码里做文本后处理；现在改成让模型按一个严格的 JSON Schema 输出结构化结果，文字部分只保留结论性内容，排版和润色交给模板。同样一个“写周报摘要”的活儿，原来的输出 token 在 800 到 1200，现在压到 300 左右。输出 token 通常比输入 token 贵，这部分省下来的不是小数目。

2.3 KV 缓存和前缀复用：省下的 token 要算进成本账

还有一个容易被忽略的省钱点：KV cache 和前缀复用。我们之前有一个坏习惯，prompt 前缀经常改，系统提示语三天两头动。后来发现，凡是带缓存的 API 或自建推理服务，系统提示语的变动会让整个 prompt 前缀的缓存全部失效，这就意味着每次请求都要重新计算一遍所有的 key 和 value，成本自然压不下来。

这周我们把系统提示语纳入版本管理，不再随便改，同时在服务端开启了前缀缓存。实测下来，对于那种长 prompt、短输出的任务，缓存命中率能到 60% 以上，在线费用评估里每百万 token 的花费下降了三成左右。另一个做法是把高频工具描述放到 prompt 的固定位置，因为工具定义的描述性文本很长，放前面并保持稳定，能让“上一轮计算过的部分”直接复用。

想提醒的是，做 token 成本优化，一定要把“节省了多少”这件事落到数字上。我们建了一张简单的表，每周统计一次：

省 token 和省钱不完全是同一件事，但如果你连数字都没统计，那后面做任何优化决策，都是拍脑袋。这周的体会是：token 变少不是靠“更小模型”这个单一动作，而是靠把任务分得更细，让每个任务只拿到它需要的最小上下文。

3. “更强模型”带来的工程重估：选型、长文本和部署格局

3.1 能力越强，重新评估的任务分派就越多

模型能力变强，对我们的直接冲击不是“哇，什么都能干”，而是“我们得重新决定，什么事该让它干”。这周我们把一个开源模型的新版本拉到内部评测集上跑了一遍，代码能力确实惊喜，之前要两三次提示才能修正的复杂函数生成，现在一次就能写对。但反过来，正因为它的输出更像“人写的”，我们开始担心一个以前不太在意的问题：代码审查里，模型生成的高质量代码是不是反而更难被发现问题？

这种担心不是矫情。之前模型输出有明显模板痕迹，一眼就能看出“这是生成的”，大家自然带着警惕去审查。现在生成的代码跟人写的混在一起，审查者很容易放松。我们在内部提了个流程要求：凡模型生成的代码合并到主干，diff 记录里必须标注生成来源。这是一个很微小的改动，但这周因为它，我们提前发现了一个 SQL 注入式的拼接问题。

还有一个更实际的变化：能力强的模型让“一刀切”的路由策略变得更危险。以前简单任务用 7B 模型，复杂任务用旗舰模型，边界很清楚。现在 7B 模型在某些任务上表现好得超出预期，但换个任务又突然拉胯。举个例子，我们有个开源模型抽取地址信息，准确率 98%，看着已经可以顶替大模型了；但换到抽取金额和日期混合的字段，准确率直接掉了 12 个百分点。所以每次模型更新，不管是大模型还是小模型，路由表都要重新跑一遍评测，这是能力变强之后的新常态。

3.2 长上下文模型让“全文理解”和“切片检索”重修边界

这周我们测了一个支持百万级 token 上下文的新模型，正好手头有一批超长合同要走分析，团队里立刻冒出两种声音：一种说“以后不用做切片了，整个合同丢进去让模型读”；另一种说“长上下文就是障眼法，最后还是得靠检索”。

我的观点是两边都对，但要分场景。我们对十份真实合同做了对比：用长上下文模型直接读全文，和用原有的“切片加摘要加拼接”方案比，在最终结论的事实一致性上，全文读取反而高了 8 个百分点。原因不难理解：切片方案在跨章节引用上天然吃亏，合同里的定义条款和后面的执行条款经常隔着几十页，切片时早就被切散了。

但全文读取的代价是 token 消耗陡增，而且模型需要额外时间“翻完整本书”。所以我们的结论是：长文本场景要重新按“文档篇幅”和“任务类型”分流。短到中篇、需要全局理解的，直接全文进模型，省去切片；超长篇幅、只需要定位特定条款的，还是切了检索更划算，用“检索定位，发现相关段落，再全文精读某一局部”的混合方式。

3.3 本地模型与云端模型的中间件格局

这一周另一个明显感受是：本地模型的戏份变多了。之前本地部署更多是“探索”，这周我们真的把一批数据敏感、不方便出内网的中间处理任务，放到了本地跑的模型上，配套做了一层轻量调度，作为云端大模型的“前置处理器”。

举个例子，我们有个环节要做 PII 检测和字段脱敏，原本也考虑过云端 API，但数据审计那边不同意，后来就用本地部署的小模型跑。与此同时，同一批文档的“总结归纳”这类非敏感任务，又走云端大模型，因为云端模型在总结质量上还是高一截。这个“敏感数据先本地过滤，非敏感任务再上云端”的分工模式，这周跑下来很顺。

但本地部署的坑也不少，最直接的是显存、并发和模型版本管理。我们踩了一个挺典型的坑：本地模型服务没有做版本管理，某天某个人改了模型路径配错了版本目录，线上任务静默跑了两小时，输出的字段结构全变了，还好有日志回放才发现。后来我们把模型目录放进版本库约束，跟代码发布一起走 CI，才算解掉这个隐患。

基于这周的体会，我给模型选型画了一张简表，适合大多数中小团队参考：

模型越强，选型的空间越大，但选型之后的路由表、评测集、版本管理这些工程基建也得跟着变重。我的感受是，“模型能力”本身已经不太是瓶颈，瓶颈反而在于我们有没有能力把不同强度的模型，放在它们各自合适的位置上。

4. “更难管的 agent”：失控、观测、并发与评估

4.1 一个活生生的失控案例：循环调用、预算超支和迟到的拦截

这周我们两个 agent 出事，第一个是最典型的“工具调用失控”。那个资料收集 agent 的任务是“根据用户主题，收集 5 到 10 条相关网页摘要，并整理成报告”。听起来是个边界很清晰的任务，但用户给的当前主题有点模糊，于是 agent 开始“自我怀疑”：它每搜索一次，就觉得自己搜得不够准，于是换关键词再搜一次，搜完又对摘要不满意，再搜。日志显示它在一个小时内连续调用了 12 次搜索工具，而且有 4 次搜索词几乎一样，只是换了语序和同义词。

最后账单出来，光这一个任务就烧了将近 10 万 token，而产出的报告只有 3 条有效摘要，其余全是重复和低相关内容。我们查链路的时候发现，拦截机制不是没有，而是设错了位置——超时和 token 上限设在了“单次工具调用”级别，没设在整个 agent 会话级别。每个工具调用本身都是合规的、低成本的，但串成一个循环之后，总成本就失控了。

修复不复杂：给 agent 增加了“单会话工具调用上限”，默认 6 次，超了必须进入“总结已获得信息并停止”；同时给搜索工具的调用加了一个置信度自评环节——如果当前搜索结果的相关性评分低于阈值，agent 可以结束任务而不是继续搜。另外在调度层加了一个总 token 预算的熔断，超过预算直接把 agent 置为失败态，不让它“自行解释”。

这个案例给我最大的教训是：管 agent 不能只看单步，要看整条轨迹。单步都合规，不代表整条轨迹合理。

4.2 可观测性补课：每个 step 都要留下痕迹

出事的当天下午，我们就开始给 agent 补可观测性。以前我们常规的 API 日志只记录了“一次请求的入参和出参”，但 agent 这种多步决策系统，必须记录每一个 step 的完整轨迹，否则复盘只能靠猜。

我现在推荐一套非常朴素的方案，谁都能照抄：

• 每个 step 记录：当前子任务的描述、使用的工具、工具入参（敏感字段脱敏）、工具返回的摘要、agent 的中间思考、到达的中间结论。
• 每条轨迹都绑定一个 trace_id，从用户请求开始一路透传到每一步工具调用。
• Token 消耗按 step 拆分统计，这样出了问题能明确知道是“哪一步烧掉了大量预算”。
• 增加回放能力：把存下来的轨迹重新跑一遍，看同样的输入会不会复现同样的决策。

可观测性补上之后，第二个 agent 的问题一下就清楚了。它在多步拆解时，把“分析数据”理解得太宽泛，每拆一步就往更大的范围扩散一次。数据链路里能看到它逐步把查询范围从“当前文档”扩大到“项目全部文档”再到“所有历史版本”，这就是决策链路的漂移，如果只看最终输出，大概率只会觉得它“结果不对”，根本不知道它中间怎么一步步走偏的。

4.3 并发放大问题，权限模糊化更危险

这周还有一个很有意思的现场：两个 agent 同时跑同一种任务，结果互相踩了共享状态的坑。我们有个工作流里，agent 会往一个共享的状态表里写入中间进度，之前是单 agent 跑，没出过问题。这周为了提升效率，开了并发 3 个 agent，结果三个 agent 同时写同一行状态，互相覆盖，最后任务状态全乱了。

这个坑的根因不是并发库的问题，而是我们默认了“agent 像单个函数一样执行”，没想过并发下 agent 的共享状态怎么写。后来引入了一个简单的 per-agent 隔离：每个 agent 实例有自己的状态空间，只在任务结束时把最终的汇总结果写入共享表，整个过程加锁。一句话总结就是：agent 并发的时候，不要让多个智能体共享同一个可变状态，除非你有分布式事务级别的准备。

权限模糊化也要特别提一下。我们用 agent 偶尔会让它直接操作数据库或调用内部 API，最初设计的时候图省事，给的是“超集权限”——什么都能查。这周复盘时意识到，这是一个很危险的默认值。agent 决策不可预测，如果它的权限边界跟人一样宽，那一次“计划外”的工具调用就可能造成远超预期的后果。后来我们做了两件事：一是按角色收敛权限，给每个 agent 设置最小权限集，只能调用它实际需要的那两三个工具；二是在工具层加了一个审批钩子，对于删除、批量写这类危险操作，一律要求二次确认，不管 agent 在 prompt 里怎么说都不直接放行。

4.4 没有 eval 集，agent 重构就是赌运气

这周我们还做了一个决定：给 agent 建一个最小可用的评估集。以前我们评估 agent 基本靠“人肉看几个案例”，换个大模型或者改个 prompt，就主观判断“好像变好了”。但 agent 这种系统，经常是修好了一个场景、弄坏了三个场景，没有回归测试，重构完全就是赌运气。

我们现在建了一个小样本的黄金集，大概二十个任务，覆盖正常场景、边界输入、需要中止的场景，每个任务都有期望的结果描述和关键事实点。评估方式用“模型当裁判”加“人工抽检”混合：每个任务的输出拿给一个独立的评估模型打分，重点看事实一致性和步骤完整性，每周再抽五条让真人复核。

第一次跑这个评估集的时候，效果比我预想得好——之前我们都觉得“这周 agent 表现不错”，结果评估集里二十个任务只过了十四个，有好几个是“输出看起来很完整，但关键步骤其实漏了”。这就是评估集的价值，它逼着你把“感觉”变成“数字”。这个教训也让我意识到，所谓“更难管的 agent”，本质不是 agent 变坏了，而是我们评估 agent 的能力没有跟上 agent 自身的发展速度。

5. 这一周我们实际推进的工程动作

5.1 建立 token 基线表格和工作流

这周做的所有事情，最后沉淀成了一套可复用的动作，我简单列一下，都是可以直接抄作业的。

周一早上第一件事，是给所有核心接口建立 token 基线。我们做了一个脚本，每天自动抽取线上请求样本，按接口维度统计输入 token、输出 token、p50 和 p95 延迟，然后跟上一周做对比。这个基线表挂在项目的 dashboard 上，谁改 prompt、谁换模型，数字一变就能看出来。这周能发现 token 明显下降，靠的就是这张表，不然凭感觉根本对不上账。

5.2 给 agent 加“马甲”：harness、护栏和退路

针对 agent 的管控，我们这周定了一个“三件套”配置，我把它叫做给 agent 穿马甲：

• 任务范围声明：每个 agent 启动时，必须带上一个人工编写的任务边界描述，说明“你可以做什么、你不可以做什么、什么时候必须停下来”。
• 工具调用配额：按会话维度限制工具调用次数和总 token 预算，超过直接结束并返回当前结论。
• 降级退路：agent 一旦失败，必须有 fallback 路径。要么转人工，要么用规则引擎兜底，不允许“失败即静默”。这个退路以前没人管，这次事故之后补上了。

这三件套看着简单，但真正落实的时候需要不少细节。比如任务范围声明，不能写在系统提示语的最后一行，要放到 agent 的控制逻辑里，agent 每次决策前必须先过一次边界检查。工具配额也不能写死在代码里，要在配置中心动态调整，因为不同任务的合理配额差异很大。

5.3 周五评审会定下的三项约定

周五的复盘会，我们没有搞大而全的议程，就定下了三件事：

一，从下周开始，所有模型变更、prompt 变更，必须先跑评估集，评估结果低于当前基线的不允许上线。二，agent 的日志回放纳入日常巡检，每周随机抽三条完整轨迹做人工评审，重点看有没有“越走越偏”的决策漂移。三，token 优化指标从“总量下降”调整为“单次有效请求的 token 下降”，防止团队为了省 token 而牺牲任务完成度。

这三项的初衷是一致的：在模型和 agent 越来越强的时代，工程的职责不是“让系统跑得更快”，而是“让失控的成本可预见、可拦截、可追溯”。

我之前有一段时间总觉得，AI 工程的重点是跟着模型走，模型强了，一切都会自动变好。这周过完我彻底改观了——模型能力越强，token 规划、权限边界、轨迹可观测这些东西反而越重要。这有点像一个悖论：工具越强大，对使用者自律的要求越高。agent 越自主，工程上越要给它划出更清晰的“不能做”清单。这条线划得好不好，可能才是未来 AI 应用项目能不能稳定跑下去的胜负手。