1. 模型选型只是入场券真正决定成败的是它下面那三层过去一年多我参与过不少 AI 项目的落地也帮朋友的公司做过技术咨询。一个反复出现的场景是团队花了两周时间对比各种大模型的跑分、价格、上下文长度最后选了一个“性价比最高”的结果上线之后发现效果根本达不到预期。然后大家开始怀疑模型不行换一个再试还是不行。折腾几轮下来项目就黄了。问题出在哪绝大多数人把注意力全放在了模型这一层而忽略了模型下面还有三层地基。我习惯把这套东西叫做AI 落地的四层架构从下往上依次是基础设施层AI Infra、协议与工具层MCP、编排与执行层Agent / Harness、模型层。模型只是最上面那一层它能不能发挥出应有的水平取决于下面三层搭得稳不稳。这篇文章不聊虚的我会把这四层分别是什么、每一层容易踩什么坑、怎么用最小的成本把架子搭起来一条一条讲清楚。不管你是刚接触 AI 应用开发的工程师还是正在推动团队落地 AI 的技术负责人看完之后至少能少走两三个月的弯路。2. 第一层AI Infra——被大多数人低估的“水电煤”2.1 AI Infra 到底包含什么很多人一听“基础设施”就觉得跟自己没关系那是大厂才搞的东西。但实际上只要你开始认真用 AI 做点事情哪怕只是给团队搭一个内部用的问答机器人你就已经在跟 AI Infra 打交道了。我理解的 AI Infra 至少包含这几块算力资源GPU 还是 CPU、本地还是云端、按量还是包年这些选择直接决定了你的响应速度和成本结构。模型服务你是直接调 API还是自己部署开源模型调 API 的话怎么做负载均衡和故障转移自己部署的话显存怎么分配、并发怎么控制数据管道你的知识库怎么更新文档怎么切分向量库怎么选检索策略怎么调可观测性请求日志、Token 消耗、响应延迟、错误率这些指标你有没有在监控这四块里面数据管道和可观测性是最容易被忽略的。我见过太多团队模型调得好好的但知识库半年没更新用户问新问题就答不上来或者上线之后从来不看好坏直到用户投诉才发现某个意图的识别率只有 30%。2.2 一个真实的翻车案例去年有个做法律咨询的朋友找我说他们用某大模型做的合同审查工具一开始效果还行但用了两个月之后准确率明显下降。我帮他排查了一圈发现问题根本不在模型身上。他们的流程是这样的用户上传合同 → 系统把合同全文塞进 Prompt → 模型输出审查意见。问题在于合同越来越长有些超过了两万字而他们用的模型上下文窗口只有 8K。超出的部分被截断了模型根本看不到后面的条款自然审不出问题。更麻烦的是他们没有做任何日志记录所以一直不知道是哪些合同出了问题。后来我建议他们做了三件事在入口处加一个文档长度检测超过阈值的走分段处理流程。把每次请求的输入长度、输出长度、耗时都记录下来存到一张表里。每周抽样人工评估 50 条结果标记好坏。这三件事做完之后他们才发现真正的问题分布30% 的 bad case 是因为文档截断40% 是因为合同里的表格没有被正确解析剩下 30% 才是模型本身的理解偏差。这就是 AI Infra 的价值它不直接产生智能但它决定了智能能不能稳定、可靠、可观测地交付到用户手里。2.3 小团队怎么低成本搭 Infra不是每个团队都有资源搞一套完整的 MLOps 平台。我的建议是先从最小可用的方案开始模型服务初期直接调 API不要自己部署。等你的日均请求超过一定量级再考虑自建推理服务。数据管道用现成的向量数据库托管服务文档切分先用最简单的按段落切后面再优化。可观测性哪怕只是把请求日志写到一张数据库表里也比什么都没有强。关键字段包括时间戳、用户 ID、输入摘要、输出摘要、Token 数、耗时、是否报错。成本控制给每个用户或每个团队设置每日 Token 上限防止意外刷量。这些看起来很简单但能坚持做下来的团队不多。而恰恰是这些“简单”的事情决定了你的 AI 应用能不能从 Demo 走到生产。3. 第二层MCP——让模型真正“能做事”的协议层3.1 MCP 解决了什么问题MCP 全称是 Model Context Protocol翻译过来叫“模型上下文协议”。这个名字听起来很学术但它的核心思想特别朴素让模型能够以一种标准化的方式调用外部工具和数据源。在没有 MCP 之前如果你想让模型查数据库、读文件、调 API你得为每个工具单独写一套对接代码。模型 A 的 function calling 格式和模型 B 的不一样今天接了这个工具明天换个模型又得重写。MCP 的出现就是为了解决这个碎片化的问题——它定义了一套统一的协议工具提供方按照这个协议暴露自己的能力模型侧按照这个协议去调用两边解耦。你可以把它理解成 AI 世界的 USB 接口。以前每个设备都有自己的充电口现在统一成 Type-C谁都能插。3.2 MCP 的典型使用场景我目前在实际项目中用到 MCP 的场景主要有这几类数据库查询让模型直接连到业务数据库用自然语言查数据。比如“上个月华东区的销售额是多少”模型自动生成 SQL 并执行。文件系统操作让模型读取本地或云端的文档、表格、代码文件进行总结、修改、生成。浏览器自动化通过 Playwright MCP 这类工具让模型能够操作浏览器完成网页抓取、表单填写、截图等任务。设计工具对接比如蓝湖 MCP可以让模型直接读取设计稿的信息辅助生成前端代码。这些场景的共同点是模型不再只是一个“聊天机器人”而是变成了一个能真正操作数字世界的执行者。3.3 接入 MCP 时最容易踩的三个坑第一个坑权限控制形同虚设。很多人接 MCP 的时候直接给模型开了数据库的读写权限。这是非常危险的。模型可能会生成 DELETE 或 UPDATE 语句一旦执行就是生产事故。我的做法是给模型的数据库连接一律只读而且只开放必要的几张表或视图。第二个坑没有做超时和重试。MCP 调用外部工具是有网络延迟的如果工具端挂了或者响应慢模型侧会一直等。我一般会设置 10 秒超时超时后让模型走降级逻辑比如告诉用户“当前查询服务不可用请稍后再试”。第三个坑工具描述写得太随意。MCP 工具的描述文本是给模型看的模型会根据描述来判断什么时候该调用这个工具。如果你写的是“查询数据”模型可能不知道什么时候该用如果你写的是“根据用户提供的条件查询销售数据库中的订单记录支持按时间、地区、产品类别筛选”模型就能更准确地判断调用时机。一个实用的技巧把你写的工具描述拿给一个不了解你系统的人看如果他看完之后能准确说出“这个工具是干什么的、什么时候该用”那说明描述合格了。3.4 MCP 和 Agent 的关系经常有人问我MCP 和 Agent 到底有什么区别。我的理解是MCP 是能力层Agent 是决策层。MCP 负责“能做什么”Agent 负责“该做什么、先做什么、做完之后下一步做什么”。举个例子用户说“帮我分析一下上个月的销售数据做个图表”。Agent 会拆解任务第一步调用 MCP 查数据库拿数据第二步调用 MCP 的图表生成工具画图第三步把结果整理成文字回复。MCP 提供的是查数据库和画图这两个能力Agent 决定的是什么时候用哪个能力、怎么组合。两者配合起来才能让 AI 从“能聊天”变成“能干活”。4. 第三层Agent 与 Harness——从“能说话”到“能干活”的关键一跃4.1 Agent 的本质是什么Agent 这个词现在被用得有点泛滥什么产品都敢叫自己 Agent。但剥开外壳看本质Agent 的核心就三件事感知、决策、执行。感知理解用户意图获取当前环境的状态比如有哪些工具可用、上一步执行结果是什么。决策根据目标和当前状态决定下一步做什么。这一步通常由大模型来完成。执行调用工具或输出结果然后根据反馈进入下一轮循环。听起来简单但真正做起来难点在于循环控制。Agent 不能无限循环下去也不能一步没做完就停。什么时候该继续、什么时候该停、出错了怎么办这些都需要精心设计。4.2 Harness 是什么为什么它比 Agent 更值得关注Harness 这个词在中文里没有特别好的对应翻译我一般叫它“执行框架”或“编排骨架”。它和 Agent 的区别在于Agent 更偏向于“智能决策”的部分而 Harness 更偏向于“工程执行”的部分。一个完整的 Harness 通常包含任务队列管理待执行的任务支持优先级和依赖关系。状态管理记录每个任务的执行状态支持断点续跑。错误处理当某个步骤失败时决定是重试、跳过还是终止。结果聚合把多个步骤的输出合并成最终结果。日志与追踪记录每一步的输入输出方便排查问题。我见过很多 Agent 项目Demo 阶段很惊艳但一到生产环境就各种问题。根本原因就是 Harness 没做好。模型再聪明如果执行框架不稳定整个系统就是空中楼阁。4.3 一个 Agent Harness 的实战拆解假设我们要做一个“自动生成周报”的 Agent。用户输入“帮我生成本周周报”系统需要完成以下步骤从项目管理工具拉取本周完成的任务。从代码仓库拉取本周的提交记录。从日历中拉取本周的会议安排。把以上信息汇总让模型生成周报初稿。把初稿发给用户确认根据反馈修改。在这个流程里Harness 负责的是按顺序调度这五个步骤。如果第 1 步拉取任务失败重试两次还失败就跳过并记录。如果第 4 步模型生成超时走降级逻辑输出原始数据让用户自己整理。把每一步的耗时和结果记录下来方便后续优化。Agent 负责的是理解用户说的“本周”具体是哪几天。判断哪些任务值得写进周报、哪些可以忽略。根据会议安排和代码提交推断出本周的主要工作重点。生成自然流畅的周报文字。两者分工明确各司其职。没有 HarnessAgent 就是一个只会说不会做的“嘴炮”没有 AgentHarness 就是一个没有灵魂的流程引擎。4.4 Agent 开发中最容易犯的三个错误错误一把 Agent 当万能药。不是所有任务都适合用 Agent。如果一个任务的步骤是固定的、不需要动态决策的那直接用工作流引擎就行了没必要上 Agent。Agent 的价值在于处理不确定性和动态决策如果场景本身很确定用 Agent 反而是杀鸡用牛刀。错误二不给 Agent 设边界。Agent 需要有明确的停止条件。我一般会设置三个限制最大循环次数比如 10 次、最大执行时间比如 60 秒、最大 Token 消耗比如 50000。超过任何一个限制就强制停止并返回当前结果。错误三不做人工兜底。再好的 Agent 也会有出错的时候。关键流程一定要有人工确认环节。比如自动发送邮件之前先让用户预览自动修改数据之前先让用户确认。这不是不信任 AI而是对生产环境的基本敬畏。5. 第四层模型——最上面那一层反而最不该纠结5.1 模型选型的正确姿势回到开头那个问题为什么大家总在模型选型上纠结因为这是最容易比较的一层。跑分、价格、上下文长度这些都是明面上的数字拿来就能比。但下面三层的搭建质量是没法用数字衡量的所以大家下意识地回避了。我的建议是模型选型不要追求最优追求够用就行。具体来说先确定你的核心场景需要什么能力。是文本生成、代码生成、还是多轮对话不同模型在不同场景下的表现差异很大。用你自己的真实数据做评测不要只看公开跑分。公开跑分只能作为参考真正重要的是在你的业务场景下的表现。选一个主流模型作为主力再选一个作为备用。主力挂了或者限流了自动切到备用。不要频繁换模型。每次换模型都意味着重新调 Prompt、重新评测、重新上线成本很高。5.2 Prompt 工程在四层架构中的位置Prompt 工程属于模型层的一部分但它的重要性被很多人高估了。我见过一些团队把大量时间花在调 Prompt 上试图用 Prompt 解决所有问题。但很多问题根本不是 Prompt 能解决的。比如模型回答不准确可能是因为知识库没有更新Infra 层的问题模型无法调用外部工具可能是因为 MCP 没接好协议层的问题模型执行多步任务时中断可能是因为 Harness 没有做状态管理编排层的问题。Prompt 能解决的是“表达”问题解决不了“能力”和“流程”问题。先把下面三层搭好再在 Prompt 上做优化效果会好得多。5.3 模型层的成本优化思路模型调用成本是很多团队关心的问题。我的经验是成本优化要从三个层面入手减少无效调用很多请求其实不需要调模型。比如用户问“今天天气怎么样”如果你有天气 API直接调 API 返回就行了没必要让模型去生成。在模型前面加一层意图识别把能直接回答的问题拦截掉。控制上下文长度上下文越长成本越高。不要把整个知识库都塞进 Prompt先用检索找到最相关的几段再送给模型。分级使用模型简单任务用便宜的小模型复杂任务用贵的大模型。比如意图识别用小模型内容生成用大模型。这三招下来成本通常能降一半以上。6. 四层架构的协作逻辑为什么下面三层才是真正的护城河6.1 一个完整的请求在四层中是怎么流转的让我们用一个具体的例子把四层架构串起来。假设用户对一个电商客服 AI 说“帮我查一下我上个月买的那双鞋现在降价了吗”第一层Infra系统接收到请求记录日志检查用户身份和权限从缓存中加载用户的历史订单数据。第二层MCPAgent 判断需要调用两个工具——订单查询工具和商品价格查询工具。MCP 协议负责把这两个工具的调用请求标准化发给对应的服务。第三层Agent HarnessAgent 先调用订单查询拿到上个月的订单列表找到鞋子那一单。然后调用价格查询拿到当前价格。比较两个价格判断是否降价。Harness 负责管理这两个调用的顺序、超时和错误处理。第四层模型模型根据 Agent 提供的数据生成自然语言的回复“您上个月购买的 XX 鞋子当时价格是 499 元现在活动价是 399 元降了 100 元。需要我帮您申请价保吗”整个流程里模型只负责最后一步的文字生成。前面的数据获取、工具调用、逻辑判断都是下面三层在支撑。如果下面三层没搭好模型再强也回答不了这个问题。6.2 为什么说护城河在下面三层模型是公开的你能用的别人也能用。但你的数据管道、你的工具集成、你的执行框架是别人抄不走的。这些才是真正的竞争壁垒。我观察到一个现象那些 AI 应用做得好的团队往往不是模型用得最先进的而是工程能力最强的。他们把大量精力花在数据清洗、工具对接、流程编排、监控告警上这些工作不性感但决定了产品的下限。而产品的上限才由模型决定。问题是如果下限没守住上限再高也没用。6.3 不同阶段的团队应该优先投入哪一层刚起步的团队优先搭 Infra 层。把数据管道和日志监控做好哪怕模型用最便宜的也能跑出一个可用的产品。有一定用户量的团队重点投入 MCP 层。把常用的工具都接进来让模型能做的事情更多产品的价值就更大。追求差异化的团队在 Harness 层下功夫。把执行框架做得更稳定、更灵活支持更复杂的任务编排这是拉开差距的关键。所有团队模型层保持关注但不要过度投入。选一个主流模型用着等有明确需求了再换。7. 落地过程中那些没人告诉你的坑7.1 数据质量比模型能力重要十倍我做过一个内部知识库问答的项目一开始效果很差答非所问。我以为是模型不行换了一个更贵的还是不行。后来花了两天时间把知识库文档重新整理了一遍——去掉过时的内容、统一术语、把长文档拆成短段落、给每段加上标题——再跑准确率直接从 40% 涨到了 85%。模型没换只是数据变好了。这件事让我深刻认识到在 AI 应用里垃圾进垃圾出这句话比任何时候都成立。7.2 不要试图用 AI 解决所有问题有些问题用规则引擎就能解决而且比 AI 更稳定、更便宜、更快。比如格式校验、必填项检查、简单的条件判断这些用传统代码写就行了没必要上模型。AI 应该用在那些规则难以穷举、需要理解自然语言、需要动态决策的场景。把 AI 用在正确的地方比把 AI 用得到处都是更重要。7.3 上线只是开始运营才是重头戏很多团队把 AI 应用上线当成终点上线之后就不管了。但实际上上线只是起点。你需要持续监控效果、收集反馈、更新知识库、优化 Prompt、调整流程。我一般会建议团队建立一个“周度评估”机制每周抽 50 条真实请求人工评估结果好坏把 bad case 分类整理然后针对性地优化。这个机制看起来笨但效果非常好。坚持三个月产品的表现会有质的提升。7.4 团队能力建设比技术选型更关键最后说一点关于人的事。AI 落地不是一个人的事它需要工程、产品、运营、业务多方配合。我见过太多项目技术选型很先进但团队之间协作不畅最后不了了之。我的建议是在项目启动阶段就明确各方的职责谁负责数据、谁负责工具对接、谁负责流程编排、谁负责效果评估。定期同步进展遇到问题一起排查。技术问题往往好解决人的问题才是最难解决的。8. 回到标题卡住你的从来不是模型写了这么多其实就想说清楚一件事AI 落地是一个系统工程模型只是其中一环。把模型比作发动机那 Infra 是底盘、MCP 是传动系统、Agent 和 Harness 是方向盘和刹车。发动机再好底盘不稳、传动不畅、刹车不灵车也跑不起来。我在实际项目中的体会是当你觉得 AI 效果不好的时候先别急着换模型。往下看一层看看数据管道是不是通畅、工具调用是不是稳定、执行流程是不是可靠。十有八九问题出在下面。把下面三层搭扎实了模型的能力才能被真正释放出来。这时候你再去优化 Prompt、换更强的模型才会看到明显的提升。顺序反了花再多钱也是打水漂。最后分享一个我常用的排查思路当 AI 应用出问题时从下往上查——先看 Infra 层的日志和监控再看 MCP 层的调用记录再看 Harness 层的执行状态最后才看模型的输入输出。这个顺序能帮你快速定位问题所在避免在错误的地方浪费时间。