1. 为什么模型不是AI落地的瓶颈过去一年多我参与过六七个AI落地项目从客服工单自动分类到代码仓库智能巡检从合同要素抽取到内部知识库问答。每次项目复盘团队里总有人把问题归结为“模型不够强”——换个更大的参数、换个更新的版本、换个榜单排名更高的开源权重似乎一切就能迎刃而解。但真实情况是模型能力只是整个系统里最容易被替换的一层真正让项目卡住、延期、甚至悄无声息死掉的几乎都发生在模型之外。我见过太多这样的场景一个团队花了两周时间对比不同模型的评测分数最后选了一个“最强”的结果上线第一天就被业务方投诉“答非所问”。排查下来发现不是模型理解错了而是检索回来的上下文本身就是错的——知识库里的文档版本混乱切片策略把关键表格切成了碎片向量模型对中文专业术语的语义区分度不够。模型拿到一堆垃圾上下文再强也只能输出垃圾。这就是典型的“模型背锅”。所以我想把AI落地这件事拆成四层来看模型层、Harness层、Agent层、Infra层。这四层从下到上越往上越贴近业务越往下越贴近基础设施。模型层是大家最关注的但恰恰是标准化程度最高、可替换性最强的一层。Harness层负责把模型能力“约束”成可用的输出Agent层负责把单次调用编排成多步任务Infra层负责让这一切稳定、可观测、可扩展。真正卡住你的从来不是模型而是上面这三层。这篇文章适合谁看如果你正在做AI应用开发或者准备把大模型接入现有业务系统又或者你是一个技术负责人需要判断团队在AI项目上的投入方向那这篇内容应该能帮你少走一些弯路。我会尽量用实际项目中的例子来说明每一层在做什么、为什么重要、以及最容易踩的坑在哪里。2. 四层架构的整体拆解与选型逻辑2.1 模型层最容易被替换的一层模型层就是大家最熟悉的那部分——调用大模型API或者本地部署开源权重。这一层的核心任务只有一个给定输入生成输出。听起来简单但实际选型时需要考虑的因素并不少。首先是能力边界。不同模型在推理、代码、多语言、长文本、指令遵循等维度上的表现差异很大。比如你要做一个代码审查助手那代码理解和生成能力就是第一优先级如果你要做的是客服对话摘要那长文本压缩和关键信息提取能力更重要。我一般会建议团队先明确业务场景的核心能力需求再去对照公开评测和实际测试而不是盲目追求“全能最强”。其次是成本结构。API调用按token计费本地部署按GPU小时计费两者的成本曲线完全不同。高频低延迟的场景本地部署小模型可能更划算低频高复杂度的场景调用大模型API更经济。这里有一个简单的估算方法假设你的应用每天处理1万次请求平均每次输入500token、输出200token那一天的token消耗就是700万。按目前主流API的价格这个量级的成本是可以精确算出来的。本地部署则要考虑GPU利用率——如果请求量波动大GPU空闲时间就是浪费。第三是可控性。API调用意味着你把数据发到了外部这对很多企业来说是红线。本地部署虽然数据不出域但运维复杂度陡增。我见过一个团队为了“数据安全”强行本地部署了一个70B模型结果推理速度慢到业务方无法接受最后又灰溜溜地换回了API。所以可控性和性能之间需要权衡没有绝对正确的答案。但我想强调的是模型层的选择虽然重要但它不是一锤定音的。因为Harness层的存在你可以在不改变上层业务逻辑的情况下替换底层模型。这就是为什么我说模型层是最容易被替换的一层——只要你的Harness层设计得当换模型就像换轮胎一样虽然需要一些适配工作但不会伤筋动骨。2.2 Harness层把模型能力“约束”成可用输出Harness这个词在AI语境下我理解它是一套围绕模型的约束、引导和验证机制。你可以把它想象成马具——马本身有力量但如果没有缰绳、鞍具、马蹄铁你没法让它拉车。Harness层做的就是这件事让模型的能力被安全、稳定、可预期地使用。具体来说Harness层包含几个关键组件。提示词模板是最基础的它决定了模型看到什么、以什么格式输出。但提示词工程远不止“写一段好话”那么简单。我见过太多团队把提示词写成一坨没有结构、没有示例、没有边界条件然后抱怨模型不稳定。实际上一个好的提示词模板应该包含角色定义、任务描述、输入格式说明、输出格式约束、边界条件处理、以及至少一个few-shot示例。这些要素缺一不可。输出解析与验证是Harness层的第二道防线。模型输出的是自然语言但你的下游系统可能需要的是结构化数据。这时候就需要一个解析器把模型输出转换成JSON、XML或者特定格式。但解析器不能假设模型每次都输出完美格式——你需要处理解析失败的情况比如让模型重新生成、或者用规则兜底。我一般会建议在解析器里加一层“宽容模式”比如允许JSON里有尾随逗号、允许字段名大小写不一致这样能大幅降低解析失败率。工具调用编排是Harness层更高级的能力。当模型需要调用外部工具比如查数据库、调API、读文件时Harness层负责把工具的描述注入提示词、解析模型返回的工具调用请求、执行工具、再把结果喂回模型。这个循环就是所谓的“ReAct”模式。但这里有一个容易被忽略的细节工具调用的错误处理。如果工具执行失败了模型需要知道失败原因才能决定是重试、换工具、还是放弃。很多团队的工具调用实现里失败就是返回一个空结果模型根本不知道发生了什么只能瞎猜。安全与合规过滤也是Harness层的重要职责。模型可能生成不当内容或者被诱导执行危险操作。Harness层需要在输入和输出两端都加过滤。输入过滤防止提示词注入输出过滤防止敏感信息泄露。这部分工作往往被低估但一旦出事就是大事。2.3 Agent层从单次调用到多步任务编排如果说Harness层是让模型“说对话”那Agent层就是让模型“做对事”。Agent的核心是任务分解与执行编排。一个复杂的业务需求比如“帮我分析这个季度的销售数据并生成报告”不是一次模型调用能完成的。它需要拆解成多个步骤读取数据、清洗数据、计算指标、生成图表、撰写报告。Agent层负责把这些步骤组织起来决定每一步用什么工具、按什么顺序执行、遇到问题怎么调整。Agent的实现方式有很多种。最简单的是固定流程——你预先定义好步骤模型只负责每一步的具体执行。这种方式可控性最强但灵活性最差。稍微复杂一点的是动态规划——模型根据当前状态决定下一步做什么。这种方式灵活但容易跑偏。我一般会建议从固定流程开始等业务稳定了再逐步引入动态决策。Agent层还有一个关键问题是状态管理。多步任务执行过程中中间结果需要被保存和传递。如果任务执行到一半失败了能不能从断点恢复如果用户中途修改了需求能不能回滚到某个状态重新执行这些问题在简单场景下不明显但在复杂业务里就是刚需。我见过一个团队做合同审查Agent审查到一半发现合同版本不对结果整个流程要重头再来浪费了大量token和时间。Agent与Harness的边界也是容易混淆的地方。我的理解是Harness关注的是“一次模型调用”的输入输出处理Agent关注的是“多次模型调用”之间的编排。Harness是Agent的构建块Agent是Harness的上层应用。两者配合好了才能让AI系统真正完成复杂任务。2.4 Infra层让一切稳定、可观测、可扩展Infra层是AI系统的地基。它不直接参与业务逻辑但决定了系统能不能扛住流量、能不能快速排查问题、能不能平滑扩容。可观测性是Infra层的第一要务。AI系统的输出是不确定的同样的输入可能得到不同的输出。这意味着传统的日志和监控不够用——你需要记录每次调用的完整上下文输入是什么、模型返回了什么、Harness层做了什么处理、Agent层执行了哪些步骤、每一步的耗时和token消耗是多少。这些数据不仅能帮你排查问题还能帮你优化成本。我一般会建议至少记录以下几个维度请求ID、时间戳、模型名称、输入token数、输出token数、延迟、是否命中缓存、错误码。缓存策略是降低成本的关键。很多AI应用里大量请求是重复或相似的。比如客服场景里“怎么退货”这个问题可能一天被问几百次。如果每次都要调用模型成本会很高。缓存可以在多个层次做提示词缓存、模型输出缓存、工具结果缓存。但缓存也有坑——如果业务数据更新了缓存没失效就会返回过时信息。所以缓存策略需要和业务的数据更新频率匹配。限流与降级是保证系统稳定的必要手段。模型API有速率限制本地GPU有并发上限。当流量突增时如果没有限流机制整个系统可能雪崩。降级策略则是在资源不足时用更小的模型、更简单的提示词、或者直接返回兜底答案保证核心功能可用。我见过一个团队在促销活动期间AI客服被大量请求打挂最后只能临时关闭AI功能全部转人工。如果提前做了限流和降级至少能保住一部分自动化能力。部署与扩展是Infra层的另一个重点。AI应用通常是无状态的可以水平扩展。但模型推理是有状态的GPU内存需要特殊处理。如果你用的是API那扩展相对简单如果是本地部署就需要考虑模型服务化、请求队列、GPU调度等问题。这部分工作往往需要专门的MLOps经验不是普通后端开发能轻松搞定的。3. 核心细节解析与实操要点3.1 Harness层的提示词模板设计提示词模板是Harness层最基础也最重要的组件。我见过太多团队把提示词写得很随意然后抱怨模型不稳定。实际上一个好的提示词模板应该像一份清晰的合同——双方你和模型的权责边界要明确。我一般会遵循一个六段式结构来写提示词模板。第一段是角色定义告诉模型它扮演什么角色。比如“你是一个专业的合同审查助手擅长识别法律风险条款”。第二段是任务描述用一句话说清楚要做什么。比如“请审查以下合同文本找出其中对甲方不利的条款”。第三段是输入格式说明告诉模型输入数据长什么样。比如“合同文本将以Markdown格式提供条款之间用空行分隔”。第四段是输出格式约束这是最关键的部分。你需要明确告诉模型输出什么格式最好给出一个示例。比如“请以JSON格式输出包含risk_level、clause_text、reason三个字段”。第五段是边界条件处理告诉模型遇到不确定的情况怎么办。比如“如果合同文本不完整请在输出中标注incomplete字段为true”。第六段是few-shot示例给出一到两个完整的输入输出对让模型模仿。这个结构看起来简单但实际写的时候有很多细节要注意。比如输出格式约束如果你只写“请输出JSON”模型可能会输出带Markdown代码块的JSON或者字段名用中文或者多输出一些解释性文字。我一般会明确写“只输出JSON不要包含任何其他文字”并且在解析器里做兼容处理。再比如边界条件处理很多团队不写这部分结果模型遇到异常输入时就开始胡编乱造。明确告诉模型“如果信息不足请输出unknown而不是猜测”能大幅降低幻觉率。还有一个容易被忽略的点是提示词的版本管理。提示词不是写完就完了业务变化、模型升级、用户反馈都会导致提示词需要调整。如果没有版本管理你改了一版提示词效果变差了想回滚都找不到旧版本。我一般会建议把提示词存在数据库或配置文件里每次修改都记录版本号和变更原因方便对比和回滚。3.2 输出解析与验证的容错设计模型输出解析是Harness层的第二道防线。这里最大的坑是假设模型每次都输出完美格式。实际上即使你明确要求了JSON格式模型也可能输出带尾随逗号的JSON、字段名大小写不一致、或者嵌套结构不对。如果你的解析器直接json.loads()那解析失败率可能高达5%到10%。我一般会设计一个三级容错解析器。第一级是严格解析直接尝试标准解析。如果成功进入验证环节。第二级是宽容解析在解析前做一些预处理去掉Markdown代码块标记、修复常见的JSON语法错误比如尾随逗号、单引号、统一字段名大小写。第三级是兜底解析如果前两级都失败了就用正则表达式提取关键字段或者直接返回原始文本让下游处理。验证环节同样重要。解析出来的JSON不一定符合业务要求。比如你要求risk_level只能是high、medium、low三个值之一但模型可能输出了“较高”或者“HIGH”。这时候就需要一个验证器来检查字段类型、取值范围、必填项是否齐全。如果验证失败可以选择让模型重新生成或者用默认值填充。我一般会建议对关键字段做严格验证对非关键字段做宽松处理避免因为一个小字段格式不对就整个请求失败。这里有一个实操心得在提示词里加入“输出前请自检”的指令。比如“在输出JSON之前请检查所有必填字段是否已填写字段值是否符合要求”。这个简单的指令能显著降低格式错误率。我实测下来加了自检指令后解析失败率从8%降到了2%左右。3.3 工具调用的错误处理与重试策略工具调用是Agent层的核心能力但也是错误高发区。模型决定调用某个工具Harness层执行工具然后把结果返回给模型。这个过程中任何一步都可能出错工具本身报错、网络超时、返回格式不符合预期、模型误解了工具返回结果。我一般会设计一个工具调用包装器统一处理错误和重试。包装器需要做几件事第一超时控制。每个工具调用设置合理的超时时间避免因为一个慢工具拖垮整个Agent流程。第二错误分类。把错误分成可重试错误如网络超时和不可重试错误如参数错误。可重试错误自动重试不可重试错误直接返回给模型。第三错误信息格式化。把错误信息转换成模型能理解的格式比如“工具执行失败数据库连接超时请稍后重试或换用其他工具”。第四重试次数限制。避免无限重试导致死循环一般设置2到3次重试上限。这里有一个关键细节模型需要知道工具调用失败了。很多团队的工具调用实现里失败就是返回一个空结果或者默认值模型根本不知道发生了什么只能基于错误信息继续推理。正确的做法是把错误信息作为工具返回结果的一部分让模型看到“这次调用失败了原因是XXX”这样模型才能决定是重试、换工具、还是放弃。还有一个容易被忽略的点是工具描述的质量。模型决定调用哪个工具完全依赖于工具描述。如果工具描述写得含糊不清模型就可能调错工具。我一般会建议工具描述包含工具名称、功能说明、输入参数说明包括类型、是否必填、取值范围、输出格式说明、以及一个调用示例。描述越清晰模型调用的准确率越高。3.4 Infra层的可观测性建设可观测性是AI系统运维的基础。没有可观测性你就像在黑暗中开车——不知道系统在发生什么出了问题也不知道从哪里查起。我一般会建议至少记录以下几类数据。请求级别数据请求ID、时间戳、用户ID、会话ID、输入文本、输出文本、模型名称、输入token数、输出token数、总延迟、首token延迟。Harness级别数据使用的提示词模板版本、解析是否成功、验证是否通过、工具调用次数、工具调用耗时。Agent级别数据任务ID、任务类型、执行步骤数、每步的输入输出、任务是否成功、失败原因。Infra级别数据GPU利用率、内存占用、请求队列长度、缓存命中率、限流触发次数。这些数据收集起来容易但真正用起来需要一些技巧。我一般会建议做分层聚合实时层用PrometheusGrafana做监控告警分钟级聚合离线层用数据仓库做分析小时级或天级聚合。实时层关注异常检测比如错误率突增、延迟突增、token消耗突增。离线层关注趋势分析比如哪些提示词模板效果在下降、哪些工具调用失败率在上升、哪些用户请求成本最高。还有一个实操心得给每个请求打上业务标签。比如“客服场景”、“合同审查场景”、“代码生成场景”。这样你就能按业务维度分析成本和效果而不是把所有请求混在一起看。我见过一个团队发现整体token消耗突然上升排查了半天才发现是某个新上线的功能在疯狂调用模型如果提前打了业务标签这个问题五分钟就能定位。4. 实操过程与核心环节实现4.1 从零搭建一个Harness层的完整流程假设你要做一个合同审查助手输入是一份合同文本输出是风险条款列表。我来拆解一下Harness层的搭建过程。第一步是定义输出结构。这是整个Harness层设计的起点。你需要和业务方确认风险条款列表里每条包含哪些字段我一般会设计成clause_text条款原文、risk_level风险等级high/medium/low、risk_type风险类型如付款风险、违约责任风险、保密风险、reason风险原因说明、suggestion修改建议。这个结构确定后提示词模板和解析器都围绕它来设计。第二步是编写提示词模板。按照六段式结构来写。角色定义“你是一个专业的合同审查助手擅长识别法律风险条款”。任务描述“请审查以下合同文本找出其中对甲方不利的条款”。输入格式说明“合同文本将以Markdown格式提供”。输出格式约束“请以JSON数组格式输出每个元素包含clause_text、risk_level、risk_type、reason、suggestion五个字段”。边界条件处理“如果合同文本不完整或无法理解请输出空数组”。few-shot示例给出一段合同文本和对应的JSON输出。第三步是实现解析器。用三级容错解析器来处理模型输出。第一级严格解析第二级宽容解析去掉Markdown标记、修复常见JSON错误第三级兜底解析正则提取。解析成功后验证每个字段的类型和取值范围。risk_level必须是high/medium/low之一risk_type必须在预定义列表里。验证失败时记录日志并返回空列表或默认值。第四步是接入模型并测试。先用少量样本测试观察输出格式是否符合预期。我一般会准备20到30个测试用例覆盖正常合同、异常合同、边界情况。测试时重点关注解析成功率、字段完整率、风险识别准确率。如果解析成功率低于95%就需要调整提示词或解析器。第五步是迭代优化。根据测试结果调整提示词模板。比如发现模型经常漏掉某些风险类型就在提示词里加一个风险类型清单让模型对照检查。发现模型输出的reason太简短就在few-shot示例里给一个详细的reason示例。这个过程可能需要反复几轮直到各项指标达标。4.2 Agent层的任务编排实现继续用合同审查的例子。如果业务需求升级了不只是审查单份合同而是要“对比两份合同的差异并给出建议”那就需要Agent层来编排多步任务。第一步是任务分解。把“对比两份合同”拆解成读取合同A、读取合同B、分别审查合同A和合同B、对比审查结果、生成差异报告。每个步骤都是一个独立的子任务可以单独执行和验证。第二步是定义状态结构。Agent执行过程中需要保存中间结果。我一般会设计一个状态对象包含contract_a_text、contract_b_text、contract_a_risks、contract_b_risks、diff_result、final_report。每个步骤执行完后更新状态对象。第三步是实现步骤执行器。每个步骤对应一个函数输入是当前状态输出是更新后的状态。比如“审查合同A”这个步骤输入是contract_a_text输出是contract_a_risks。执行器内部调用Harness层来完成具体的模型调用和解析。第四步是实现流程控制器。控制器负责按顺序调用步骤执行器处理步骤之间的依赖关系以及异常情况。比如如果“审查合同A”失败了是重试还是跳过如果“对比审查结果”发现两份合同差异太大是否需要人工介入这些逻辑都在控制器里实现。第五步是加入人工确认点。对于关键步骤可以设置人工确认点。比如“生成差异报告”之前让用户确认审查结果是否准确。如果用户修改了审查结果Agent需要基于修改后的结果重新生成报告。这个机制能大幅提升业务方对AI系统的信任度。4.3 Infra层的部署与扩展方案假设你的合同审查助手要上线了预计每天处理1000份合同。我来拆解一下Infra层的部署方案。模型服务方面如果调用API需要配置API密钥、设置速率限制、实现重试机制。如果本地部署需要选择GPU型号、配置推理框架如vLLM、TGI、设置并发数。我一般会建议先用API快速上线等业务量稳定了再评估是否本地部署。缓存层方面合同审查场景里很多合同是模板化的相似度很高。可以在提示词层面做缓存如果两份合同的提示词相似度超过阈值直接复用之前的审查结果。但要注意缓存失效策略——如果合同模板更新了缓存需要及时失效。限流与降级方面设置每分钟最大请求数超过后返回“系统繁忙请稍后重试”。降级策略可以准备一个简化版的提示词模板用更小的模型牺牲一些准确率来保证可用性。监控告警方面设置关键指标告警错误率超过5%告警、平均延迟超过10秒告警、token消耗超过预算告警。告警渠道可以用邮件、短信、或者内部IM工具。日志与追踪方面每个请求记录完整链路请求ID、用户ID、合同ID、模型调用详情、解析结果、最终输出。这些日志保存至少30天方便排查问题和分析成本。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定的排查思路这是Harness层最常见的问题。模型有时候输出JSON有时候输出Markdown有时候输出纯文本。排查思路如下。先检查提示词模板。输出格式约束是否足够明确有没有说“只输出JSON不要包含任何其他文字”有没有给出JSON示例如果提示词里只写了“请输出JSON”模型很可能加上解释性文字或者Markdown代码块。再检查模型特性。不同模型对格式约束的遵循程度不同。有些模型天生更“听话”有些模型更“自由”。如果提示词已经写得很明确了但格式还是不稳定可以考虑换一个指令遵循能力更强的模型。然后检查解析器容错。解析器是否处理了常见的格式偏差比如Markdown代码块标记、尾随逗号、单引号、字段名大小写不一致。如果解析器太严格稍微有点偏差就失败那解析失败率自然高。最后检查few-shot示例。示例的输出格式是否和提示词里的约束一致如果示例里用了某种格式但提示词里说的是另一种格式模型会困惑。确保示例和约束一致。5.2 工具调用失败的常见原因与解决工具调用失败的原因很多我整理了一个速查表。失败现象可能原因排查方法解决方案模型不调用工具工具描述不清晰检查工具描述是否包含功能、参数、示例完善工具描述增加调用示例模型调用错误的工具工具描述相似度高对比不同工具的描述看是否有混淆差异化工具描述突出各自特点工具执行超时工具本身慢或网络问题查看工具执行日志确认耗时设置合理超时增加重试机制工具返回格式错误工具实现有bug检查工具返回数据格式修复工具增加返回格式验证模型误解工具返回返回信息太复杂检查返回给模型的数据是否精简精简返回信息只保留关键字段无限重试重试策略没有上限查看重试日志确认重试次数设置最大重试次数超过后返回错误这里有一个实操心得给工具调用加上“思考链”。在提示词里让模型在调用工具前先说明“我为什么要调用这个工具”这样即使调用错了你也能从思考链里看出原因。比如模型说“我需要查询数据库来获取销售数据”但实际上应该调用API那你就知道是工具描述有问题。5.3 成本超预算的排查与优化AI应用的成本很容易失控。我见过一个团队上线一个月token消耗是预算的三倍。排查下来发现几个问题提示词太长、缓存没生效、重试次数太多。提示词太长是最常见的原因。很多团队把大量业务规则、示例、说明都塞进提示词导致每次调用的输入token数很高。优化方法是把不必要的信息移到外部知识库用检索的方式按需注入精简示例只保留最关键的用更简洁的语言表达规则。缓存没生效是第二大原因。检查缓存策略是否合理缓存键是否包含了所有影响输出的变量缓存过期时间是否太短缓存命中率是多少如果命中率低于30%说明缓存策略需要调整。重试次数太多也会推高成本。检查重试策略是否对不可重试错误也进行了重试重试间隔是否太短最大重试次数是否合理我一般会建议最大重试2次重试间隔1秒。还有一个容易被忽略的点是模型选择。不是所有请求都需要用最大的模型。可以把请求分级简单请求用小型模型复杂请求用大型模型。我见过一个团队把所有请求都发给最贵的模型优化后成本降了60%效果几乎没有下降。5.4 Agent执行中断的恢复策略Agent执行多步任务时中途失败是常态。如果没有恢复策略整个任务就要重头再来浪费时间和token。我一般会设计检查点机制。每执行完一个步骤就把当前状态保存到数据库或缓存里。如果后续步骤失败了可以从最后一个成功的检查点恢复而不是从零开始。检查点需要包含任务ID、当前步骤序号、已完成步骤的输出、剩余步骤列表。状态回滚也是需要的。如果用户中途修改了需求或者发现前面的步骤结果不对需要回滚到某个检查点重新执行。回滚时要注意清理后续步骤产生的副作用比如已经写入数据库的数据、已经发送的通知。超时控制同样重要。给整个Agent任务设置一个总超时时间比如5分钟。如果超时了保存当前状态并返回“任务执行超时请稍后重试”。这样避免任务无限期挂起占用资源。这里有一个实操心得把Agent任务设计成幂等的。也就是说同一个任务执行多次结果应该是一样的。这样即使恢复时重复执行了某些步骤也不会产生副作用。实现幂等的方法包括用唯一ID标记每个步骤的执行、在写入数据前检查是否已存在、用乐观锁控制并发。6. 我踩过的坑与经验总结做AI落地这一年多踩过的坑比写过的代码还多。挑几个印象深刻的说说。第一个坑是过早优化模型。项目刚开始业务方说“效果不好”团队第一反应是换模型。结果换了三四个模型效果提升微乎其微。后来才发现问题出在检索环节——知识库里的文档切片策略有问题关键信息被切散了。调整切片策略后用原来的模型效果就达标了。所以我的经验是先排查Harness层和Agent层最后再考虑换模型。第二个坑是忽视提示词版本管理。有一次改了一版提示词上线后发现效果变差了想回滚却找不到旧版本。从那以后我强制要求所有提示词必须存在数据库里每次修改记录版本号、修改人、修改原因、测试结果。这个习惯救了我好几次。第三个坑是工具调用没有超时控制。一个Agent任务调用了某个外部API那个API挂了请求一直挂起整个任务卡死。后来加了超时控制和重试机制问题解决。我的经验是任何外部调用都必须有超时不管是模型API、数据库、还是内部服务。第四个坑是缓存失效策略太激进。为了“保证数据新鲜”缓存过期时间设成了1分钟。结果缓存命中率极低成本没降下来。后来改成按业务类型设置不同的过期时间静态知识缓存1小时动态数据缓存5分钟。命中率上去了成本也降了。第五个坑是没有业务标签。所有请求混在一起监控出了问题不知道是哪个业务场景。后来给每个请求打上业务标签按业务维度分析成本和效果定位问题快了很多。这些坑说到底都指向同一个结论AI落地的难点不在模型而在模型之外的工程化能力。Harness层决定了模型能力能不能被稳定使用Agent层决定了复杂任务能不能被自动完成Infra层决定了系统能不能扛住真实流量。把这三层做好了模型的选择反而变得不那么关键——因为你知道无论换什么模型你的系统都能把它用好。