企业官网建设流程全解析

1. 为什么模型不是AI落地的瓶颈

过去两年，我参与过十几个AI落地项目，从智能客服到文档审核，从代码辅助到数据分析。每次项目复盘，团队里总有人感叹：“要是能用上更强的模型就好了。”但真实情况是，模型能力往往不是项目失败的主因。我见过用中等规模模型跑通全流程、日均处理十万级请求的系统，也见过拿着顶级模型API却连一个稳定可用的内部工具都搭不出来的团队。

这个现象背后有一个被反复验证的规律：AI应用的效果，约20%取决于模型本身，80%取决于模型之外的那套工程体系。这套体系，我习惯称之为“Harness”——你可以把它理解成马具，模型是马，Harness是缰绳、鞍具、车轮和道路的总和。没有好的Harness，再烈的马也拉不动车。

热搜词里频繁出现的“Harness”“Agent”“Agent框架”“Harness工程”，其实都在指向同一个问题：怎么让模型在真实业务场景里稳定、可控、可维护地跑起来。这篇文章，我想把这套体系拆成四层来讲——从最底层的模型接入，到最上层的业务交付，每一层都有它自己的坑和门道。如果你正在做AI应用，或者准备启动一个AI项目，这四层架构能帮你少走至少半年的弯路。

文章会涉及一些技术选型和参数细节，但重点不在代码本身，而在为什么这么选、为什么不那么选。我会尽量用实际项目中的例子来说明，让不同基础的读者都能找到可参考的部分。

2. 四层架构的整体设计与选型逻辑

2.1 为什么是四层而不是三层或五层

在讨论具体分层之前，先说说为什么我坚持用四层。三层架构（模型层、逻辑层、交互层）在早期Demo阶段够用，但一旦进入生产环境，你会发现“逻辑层”承担了太多职责：既要管Prompt组装，又要管工具调用，还要管状态管理和错误恢复。这些职责的变更频率、技术栈、调试方式完全不同，混在一起就是灾难。

五层呢？有人会把“数据层”单独拆出来，有人会把“监控层”独立。我的经验是，数据层可以归入模型接入层（因为数据预处理和模型输入格式强相关），监控层可以归入业务交付层（因为监控指标最终服务于业务目标）。四层是一个职责边界清晰、团队分工明确、技术栈可控的平衡点。

这四层分别是：

• 模型接入层：负责与各种模型API或本地推理服务对接，处理鉴权、限流、重试、格式转换。
• 能力编排层：负责Prompt模板管理、工具调用编排、多步推理链、Agent行为控制。
• 状态与记忆层：负责会话状态、长期记忆、上下文窗口管理、检索增强。
• 业务交付层：负责与业务系统集成、输出格式化、监控告警、灰度发布。

每一层都有独立的配置、独立的测试策略、独立的负责人。当线上出问题时，你能快速定位是哪一层的锅，而不是在一团乱麻里大海捞针。

2.2 各层的核心职责与交互关系

模型接入层是唯一直接与模型打交道的层。它的核心职责是屏蔽模型差异。今天用A模型，明天换B模型，上层代码不应该感知到变化。这层需要处理的事情包括：API密钥轮换、请求频率控制、超时重试、流式与非流式响应的统一封装、Token计数与成本核算。

能力编排层是AI应用的“大脑”。它决定了一个用户请求进来后，要经过哪些步骤、调用哪些工具、以什么顺序执行。比如一个“帮我查一下上周的销售数据并生成报告”的请求，这层要拆解成：识别意图→调用数据库查询工具→调用图表生成工具→调用文本总结工具→组装最终回复。这层的设计直接决定了Agent的智能程度和稳定性。

状态与记忆层解决的是“记住”的问题。大模型的上下文窗口是有限的，但业务往往需要跨会话、跨天的记忆。这层要处理：短期对话历史怎么截断、长期记忆怎么存储和检索、用户画像怎么更新、知识库怎么动态加载。热搜词里的“滑动窗口滤波模型”其实就属于这层的技术范畴——用滑动窗口管理上下文，用滤波思路剔除无关信息。

业务交付层是最贴近用户的一层。它要回答：输出格式是Markdown还是JSON？要不要做敏感词过滤？响应时间超过多少要降级？灰度发布怎么切流量？这层的设计决定了AI能力能不能真正嵌入业务流程，而不是停留在Demo阶段。

2.3 选型背后的三个核心考量

第一，可替换性优先于性能。很多团队在选型时盯着模型跑分，却忽略了替换成本。我见过一个项目，Prompt里硬编码了某模型特有的分隔符，结果换模型时整个Prompt库要重写。正确的做法是：在模型接入层做一层适配器，把模型特有的格式差异全部吃掉，上层只看到统一的接口。

第二，可观测性优先于功能丰富度。Agent框架层出不穷，每个都宣称支持复杂编排。但如果你无法追踪一个请求经过了哪些步骤、每步耗时多少、哪步失败了，那这个框架就是黑盒。我选框架的第一标准是：能不能输出完整的执行链路日志。热搜词里的“agent execution terminated due to error”就是典型的可观测性缺失问题——出错了却不知道错在哪。

第三，渐进式复杂化优先于一步到位。不要一开始就上多Agent协作、动态规划、自我反思。先用单Agent+固定工作流跑通核心场景，再逐步引入更复杂的编排。我见过太多项目死在“过度设计”上——架构图画得漂亮，但连最基本的问答都跑不稳。

3. 模型接入层：从API到稳定服务的关键细节

3.1 模型选型的三个维度与实测对比

选模型不是选跑分最高的，而是选最适合你业务场景的。我通常从三个维度评估：

以我最近做的一个文档审核项目为例，测试了四个模型在“合同条款风险识别”任务上的表现。结果很有意思：跑分最高的模型在长文档上的表现反而不如一个中等模型，原因是长文档需要更强的上下文保持能力，而那个中等模型的训练数据里法律文本占比更高。最终我们选了这个中等模型，成本只有顶级模型的三分之一，准确率却高出5个百分点。

提示：不要迷信公开榜单。你的业务数据分布和榜单数据分布往往差异巨大，用自己的数据做盲测是唯一可靠的方法。

3.2 接入层必须处理的五件事

第一，鉴权与密钥管理。不要把API密钥硬编码在代码里。我习惯用环境变量+密钥管理服务的方式，每个环境（开发、测试、生产）用不同的密钥，并且设置自动轮换。密钥泄露是AI项目最常见的安全事故。

第二，限流与排队。模型API通常有QPS限制。接入层需要实现令牌桶或漏桶算法，把超出的请求排队而不是直接丢弃。排队策略要区分优先级：实时对话请求优先于批量处理请求。

第三，重试与降级。网络抖动、模型服务临时不可用是常态。接入层要配置指数退避重试，但重试次数不宜超过3次。如果重试后仍失败，要有降级方案：返回缓存结果、返回兜底话术、或者切换到备用模型。

第四，流式与非流式的统一。有些场景需要流式输出（如聊天），有些场景只需要最终结果（如批量审核）。接入层要提供统一的接口，让上层不需要关心底层是流式还是非流式。我的做法是：接入层始终以流式方式接收，然后根据上层配置决定是逐块返回还是聚合后返回。

第五，Token计数与成本核算。每个请求都要记录输入Token、输出Token、模型名称、时间戳。这些数据汇总后，能告诉你钱花在了哪里、哪个功能最耗Token、有没有异常调用。我见过一个项目，因为某个循环调用Bug，一夜之间烧掉了半个月的预算。

3.3 本地推理与云端API的混合部署策略

纯云端API的问题在于：成本随规模线性增长，且数据要出本地。纯本地推理的问题在于：初期硬件投入大，模型更新麻烦。我的建议是混合部署：

• 高频、低敏感、对延迟不敏感的任务走云端API，利用其弹性和低启动成本。
• 低频、高敏感、对延迟敏感的任务走本地推理，保障数据安全和响应速度。
• 接入层统一封装，上层通过配置决定路由到云端还是本地。

具体路由策略可以用一个简单的规则引擎：如果请求包含敏感字段（如身份证号、合同金额），强制走本地；如果当前云端API延迟超过阈值，自动切换到本地备用模型。这套机制在多个项目中验证过，能有效平衡成本、安全和体验。

4. 能力编排层：Agent与工作流的实战设计

4.1 Agent与工作流的本质区别与选择标准

热搜词里“harness和agent区别”被反复搜索，说明很多人对这两个概念的关系感到困惑。我的理解是：Agent是一种能力编排模式，Harness是支撑这种模式的工程体系。

Agent的核心特征是“自主决策”——它自己决定下一步做什么。工作流的核心特征是“预定义路径”——开发者提前规定好每一步。两者不是对立的，而是互补的。

选择标准很简单：

• 如果任务步骤固定、输入输出格式明确、错误处理逻辑清晰，用工作流。比如“提取发票信息→校验字段→写入数据库”。
• 如果任务需要根据中间结果动态调整策略、需要调用不确定的工具组合、需要多轮交互才能完成，用Agent。比如“帮我分析这份财报的异常点”，Agent可能需要先查数据、再算指标、再对比行业、最后生成报告，每一步都依赖上一步的结果。

我实际项目中的做法是：外层工作流，内层Agent。用工作流保证主流程的稳定性和可观测性，在需要灵活性的节点嵌入Agent。这样既不会因为Agent的不可预测性导致整个流程崩溃，又能在关键环节获得智能决策能力。

4.2 Prompt模板管理的工程化实践

Prompt不是写在代码里的字符串，而是需要版本管理的“配置资产”。我见过太多团队把Prompt散落在各个文件里，改了一个地方忘了另一个地方，导致线上线下行为不一致。

我的做法是：

• 集中存储：所有Prompt模板放在独立目录，按业务场景分文件。
• 版本控制：每次修改Prompt都提交Git，记录修改原因和测试结果。
• 变量注入：Prompt中的动态部分用占位符表示，运行时注入。比如{{user_query}}、{{context}}、{{tools}}。
• A/B测试：新Prompt上线前，用历史数据做离线评估，对比旧版本的准确率和格式合规率。
• 回滚机制：如果新Prompt导致线上指标下降，能一键回滚到上一版本。

一个实际案例：我们优化了一个客服场景的Prompt，把“请用友好的语气回复”改成了“请用友好的语气回复，并在结尾询问用户是否还有其他问题”。离线评估显示准确率没变，但上线后用户满意度提升了12%。这个改动如果散落在代码里，很可能被忽略。

4.3 工具调用的编排与错误恢复

工具调用是Agent能力的核心，也是最容易出问题的地方。常见问题包括：工具返回格式不符合预期、工具超时、工具返回空结果、多个工具调用顺序错误。

我的编排原则是：

第一，每个工具都要有明确的输入输出Schema。用JSON Schema定义工具的参数和返回值，调用前做校验，调用后做解析。这样能在早期发现格式问题，而不是等到模型生成乱七八糟的内容。

第二，工具调用要有超时和重试。每个工具设置独立的超时时间，超时后根据业务重要性决定是重试还是跳过。比如查询天气的工具超时可以跳过，但扣款的工具超时必须重试并告警。

第三，工具调用结果要缓存。同一个会话中，如果同一个工具用相同参数调用了多次，直接返回缓存结果。这能显著降低延迟和成本。

第四，错误要转化为模型能理解的语言。工具报错时，不要把原始错误堆栈直接扔给模型，而是转换成“查询失败，请稍后重试”这样的自然语言。模型看到这种信息后，会决定是重试、换工具还是告知用户。

注意：工具调用的顺序不要完全交给模型决定。对于有严格先后依赖的工具（比如先查库存再下单），应该在编排层用代码固定顺序，只把无依赖的工具选择权交给模型。

4.4 多步推理链的稳定性保障

多步推理链（Chain-of-Thought）能提升复杂任务的准确率，但也引入了新的不稳定因素：中间步骤出错会传播到后续步骤，而且很难定位是哪一步出的问题。

我的保障措施包括：

• 每步输出结构化：要求模型每步输出JSON格式，包含step、thought、action、result字段。这样即使某步出错，也能快速定位。
• 关键步骤双模型验证：对于金额计算、日期解析等关键步骤，用两个不同模型分别执行，结果一致才继续，不一致则人工介入。
• 最大步数限制：设置推理链的最大步数（通常5-8步），超过则终止并返回当前最佳结果。防止模型陷入循环。
• 中间结果持久化：每步的结果都写入日志或数据库，便于事后分析和复现。

5. 状态与记忆层：让AI记住该记住的

5.1 上下文窗口管理的滑动窗口策略

大模型的上下文窗口是有限资源。一个客服对话可能持续几十轮，全部塞进上下文既昂贵又低效。滑动窗口是最常用的策略：只保留最近N轮对话，更早的对话要么丢弃，要么压缩成摘要。

但简单的滑动窗口有个问题：它可能丢掉关键信息。比如用户在第三轮提到了订单号，第十轮问“我的订单到哪了”，如果窗口只保留最近5轮，订单号就丢了。

我的改进方案是加权滑动窗口：

• 最近3轮对话：完整保留。
• 第4-10轮：保留用户消息和AI回复的摘要。
• 第10轮之前：只保留提取出的关键实体（订单号、日期、金额等）。

这样既控制了Token消耗，又保住了关键信息。实现上，可以用一个轻量级模型做摘要和实体提取，成本远低于把全文塞进上下文。

5.2 长期记忆的存储与检索方案

长期记忆解决的是跨会话的记忆问题。比如用户上周咨询过退货政策，这周又来问，系统应该记得他之前的问题。

我的方案是向量数据库+结构化标签：

• 每轮对话结束后，提取关键信息存入向量数据库，同时打上用户ID、时间戳、主题标签。
• 新会话开始时，用当前问题去向量数据库检索相关历史记忆，取Top-K条注入上下文。
• 对于确定性信息（如用户偏好、历史订单），存入关系型数据库，检索时直接查询。

检索策略上，我习惯用“语义相似度+时间衰减”的混合排序：语义相似度高的优先，但太久远的记忆权重降低。这样既能找到相关内容，又不会让半年前的旧事干扰当前对话。

5.3 检索增强生成在业务中的落地要点

RAG（检索增强生成）是当前最实用的AI落地技术之一。但很多团队做RAG的效果不好，问题往往出在检索环节而不是生成环节。

我的RAG落地要点：

第一，文档切分要按语义而不是按字数。固定字数切分会把完整段落切碎，导致检索到的片段缺乏上下文。我习惯用“标题+段落”的方式切分，每个片段包含一个完整的小节。

第二，检索要混合稠密和稀疏。纯向量检索对关键词不敏感，纯关键词检索对语义变化不敏感。混合检索（如BM25+向量）能显著提升召回率。

第三，重排序不能省。检索出Top-20后，用一个交叉编码器做重排序，取Top-5注入上下文。这一步能提升准确率10-20个百分点。

第四，引用要可追溯。生成的回答要标注引用了哪些文档片段，方便用户核实和反馈。这不仅是体验问题，也是合规要求。

6. 业务交付层：从能用到好用的最后一公里

6.1 输出格式控制与敏感信息过滤

模型输出是自然语言，但业务系统往往需要结构化数据。输出格式控制的目标是：让模型输出可直接被下游系统消费的内容。

我的做法是：

• 在Prompt中明确要求输出JSON格式，并给出Schema示例。
• 用JSON Schema校验输出，不合规则自动重试或修复。
• 对于关键字段，用正则表达式做二次校验（如金额格式、日期格式）。
• 敏感信息过滤放在输出之后、返回之前，用规则引擎+模型双重过滤。

敏感信息过滤要特别注意：不要只过滤明显的敏感词，还要过滤模型可能“编造”的敏感信息。比如模型可能生成一个不存在的身份证号，虽然格式正确但属于虚构信息。我的做法是：对模型生成的任何实体信息，都要与知识库交叉验证，验证不通过则标记为“待确认”。

6.2 灰度发布与效果监控体系

AI应用不能一次性全量上线。我的灰度策略是：

• 第一周：内部用户试用，收集反馈，修复明显Bug。
• 第二周：1%真实流量，对比新旧方案的核心指标（准确率、响应时间、用户满意度）。
• 第三周：10%流量，观察系统稳定性，调整限流和降级阈值。
• 第四周：50%流量，准备回滚方案。
• 第五周：全量，持续监控。

监控指标分三层：

6.3 成本控制与性能优化的实战技巧

AI应用的成本主要是Token消耗和推理算力。我的优化技巧：

第一，缓存一切可缓存的。相同问题、相同上下文的请求，直接返回缓存结果。缓存粒度可以到“用户+问题+上下文摘要”。

第二，用小模型做路由。用一个轻量级模型判断请求的复杂度，简单请求走小模型，复杂请求走大模型。这能降低30-50%的成本。

第三，压缩Prompt。定期审查Prompt，删除冗余描述，用更简洁的表达。一个实际案例：我们把一个系统Prompt从800字压缩到300字，效果不变，成本降低15%。

第四，批量处理。对于非实时任务，攒一批请求一起发送，利用模型的批量推理能力。这能提升吞吐量并降低单位成本。

第五，设置预算硬上限。每天/每月的Token消耗设置硬上限，达到后自动降级到备用方案或暂停服务。这能防止意外流量导致的成本失控。

7. 常见问题与排查技巧实录

7.1 模型输出不稳定的排查思路

模型输出不稳定是最高频的问题。表现包括：同样的问题有时回答正确有时错误、输出格式时好时坏、语气忽冷忽热。

排查步骤：

1. 检查温度参数：温度过高会导致随机性增大。对于需要稳定输出的场景，温度设为0或0.1。
2. 检查Prompt一致性：确认线上线下用的是同一个Prompt版本。
3. 检查上下文污染：历史对话中是否有错误信息被反复引用。
4. 检查模型版本：模型服务商可能静默更新了模型版本，导致行为变化。
5. 做A/B测试：用相同输入跑100次，统计输出分布。如果分布过于分散，说明需要降低温度或增加约束。

7.2 Agent执行中断的常见原因与修复

“agent execution terminated due to error”是热搜词，说明很多人遇到了这个问题。常见原因：

我的经验是：Agent的每一步都要有超时、重试和降级。不要假设任何一步会永远成功。

7.3 成本超预算的紧急止血方案

如果发现Token消耗异常增长，按以下顺序排查：

1. 看调用量：是不是有异常流量或循环调用。
2. 看单次消耗：是不是Prompt变长了或上下文变大了。
3. 看模型分布：是不是大量请求走了贵模型。
4. 看缓存命中：是不是缓存失效导致重复计算。

紧急止血措施：

• 立即启用预算硬上限，超出后降级到小模型或返回缓存。
• 对非核心功能临时关闭AI能力。
• 对高频但低价值的请求增加限流。
• 回滚最近上线的Prompt或模型变更。

7.4 效果不达预期的系统性检查清单

当AI应用效果不好时，按这个清单逐项检查：

• [ ] 模型选型是否匹配任务类型？
• [ ] Prompt是否清晰、无歧义、有示例？
• [ ] 上下文是否包含了必要的信息？
• [ ] 工具调用是否稳定、返回格式是否规范？
• [ ] 输出格式是否被下游系统正确解析？
• [ ] 评估指标是否合理、是否与业务目标对齐？
• [ ] 测试数据是否覆盖了真实场景的多样性？
• [ ] 是否有足够的Bad Case分析和迭代？

我个人的体会是：80%的效果问题可以通过优化Prompt和上下文解决，15%需要调整工具和编排，只有5%需要换模型。所以遇到效果问题，先从Prompt和上下文入手，不要急着换模型。

8. 从项目实战中沉淀的几条硬经验

做了这么多AI落地项目，有几个教训是反复验证的：

第一，先跑通再优化。不要一开始就追求完美架构。用一个最简单的方案（单模型+固定Prompt）跑通核心场景，拿到真实反馈后再逐步引入Agent、RAG、多模型路由。我见过太多项目在架构设计阶段花了三个月，结果发现核心场景根本不需要那么复杂。

第二，可观测性不是可选项。每个请求的完整链路日志、每步的输入输出、每步的耗时和成本，这些数据在排查问题时价值连城。我习惯在项目第一天就搭好日志和监控，而不是等出问题了再补。

第三，人工兜底永远要有。无论AI多智能，都要有一个人工介入的通道。当AI置信度低、当用户明确要求转人工、当系统出现异常时，能无缝切换到人工。这不是AI能力不足的表现，而是对用户负责的设计。

第四，迭代速度比初始质量更重要。AI应用的效果是迭代出来的，不是设计出来的。建立一个快速迭代的闭环：收集Bad Case→分析原因→调整Prompt或编排→离线评估→灰度上线→收集新Case。这个循环越快，效果提升越明显。

第五，成本意识要贯穿始终。每次设计决策都要问：这会让成本增加多少？有没有更便宜的替代方案？我见过一个项目，因为用了过于复杂的Agent编排，单次请求成本是简单方案的20倍，但效果只提升了5%。这种投入产出比是不可持续的。

最后分享一个小技巧：在项目初期，用一个Excel表格记录每次Prompt修改、模型切换、参数调整的效果变化。这个表格会成为团队最宝贵的知识资产，比任何文档都实用。