1. 这场四小时会议到底聊了什么1.1 从一份整理稿说起为什么大家都在找这份PDF最近技术圈里流传着一份名为“梁文峰DeepSeek 4小时会议原整理”的PDF文档热度高得离谱。我前后翻了三遍也跟几个做模型部署和Agent开发的朋友聊了聊发现大家关注的点其实很集中DeepSeek接下来到底往哪走、AGI的路径怎么落地、Agent和开源生态怎么配合。这份整理稿之所以被疯传不是因为它有什么惊天猛料而是它把很多从业者心里模糊的判断给说透了。如果你是大模型应用开发者、Agent方向的产品经理、或者正在做本地化部署的技术负责人这份内容值得你花时间逐段拆。它不教你怎么调API也不给你现成的代码但它回答了一个更底层的问题当模型能力不再是瓶颈时工程侧该往哪个方向使劲。我见过太多团队在选型时纠结参数规模、纠结榜单排名却忽略了模型背后那套“怎么用、怎么接、怎么管”的工程逻辑。这份整理稿的价值恰恰在于它把视角从“模型本身”拉到了“模型怎么变成生产力”这一层。1.2 四个小时的核心脉络从模型能力到工程落地整场会议的信息量很大但主线其实很清晰。我把它拆成四条线来看第一条是模型能力的边界认知也就是当前大模型能做什么、不能做什么哪些是 scaling law 还能继续推的哪些是需要架构层面创新的第二条是Agent的定位Agent不是简单的“模型加工具调用”而是一套完整的任务分解、执行、反馈、修正的闭环系统第三条是开源策略开源不是做慈善而是构建生态护城河的手段关键在于开什么、怎么开、什么时候开第四条是AGI的阶段性判断哪些能力已经具备哪些还差得远从业者应该把精力押在哪里。这四条线不是孤立的它们相互咬合。比如Agent的落地效果直接取决于模型能力的边界而开源策略又会影响Agent生态的繁荣程度。我在实际做Agent项目时最深的一个体会就是模型再强如果工程链路没搭好用户体验就是断崖式下跌。会议里提到的很多点其实都是在解决这个“最后一公里”的问题。1.3 谁适合逐字精读这份整理稿这份内容不是给纯小白看的入门指南也不是给只关心API价格的调用方看的。它更适合三类人第一类是做AI应用架构的工程师你需要判断技术选型的长期方向知道哪些能力会变成基础设施、哪些只是过渡方案第二类是做Agent产品的负责人你需要理解模型能力和工程能力之间的配合关系避免把产品设计建立在错误的假设上第三类是关注开源生态的开发者你需要看懂开源项目背后的战略意图才能选对参与方式和技术栈。如果你只是想知道“DeepSeek下一个版本什么时候发”那这份整理稿可能让你失望。但如果你想搞清楚“未来一年大模型工程侧的重心在哪里”那它值得你反复读。我自己在读的时候把其中关于Agent执行链路和开源协作模式的部分单独摘出来做了笔记后来在项目里调整了两个关键设计效果提升很明显。2. 模型能力边界哪些事现在就能做哪些还得等2.1 大模型不是AGI但它是AGI的必经之路会议里有一个判断我特别认同大模型不是AGI但它是通往AGI路上绕不开的一步。很多人喜欢把这两个概念混在一起聊结果要么过度乐观觉得再过两年什么都能自动搞定要么过度悲观觉得大模型就是个高级鹦鹉。这两种极端都会导致技术决策变形。从工程视角看当前大模型的核心能力集中在语言理解、知识检索、模式补全、简单推理这四个维度。它在处理结构化明确、上下文充分的任务时表现很好比如代码补全、文档摘要、客服问答。但一旦任务需要长链条规划、多步验证、环境交互模型的短板就暴露出来了。这不是模型不够大而是架构层面的限制。我在做Agent项目时最头疼的就是模型能理解每一步该做什么但连续做十步之后它会把第三步的结论忘掉或者把第五步的目标和第七步的目标搞混。所以会议里反复强调一个观点不要指望模型自己解决所有问题工程侧要做的是把复杂任务拆成模型能处理的粒度。这听起来像废话但实际操作中很多团队就是卡在“拆得不够细”或者“拆得太细导致上下文爆炸”这两个极端之间。2.2 推理能力的真实水平别被榜单忽悠了现在各种榜单满天飞MMLU、GSM8K、HumanEval分数一个比一个高。但会议里提了一个很实在的观点榜单分数和实际可用性之间有一条巨大的鸿沟。原因很简单榜单题目通常是单轮、封闭、有标准答案的而真实场景是多轮、开放、答案模糊甚至没有标准答案的。我拿一个实际案例来说明。我们之前做一个合同审核的Agent模型在测试集上的准确率能到92%但上线之后用户投诉不断。排查下来发现问题出在合同条款之间的交叉引用上。测试集里的合同都是单页的条款之间没有复杂引用但真实合同动辄几十页条款A引用条款B条款B又依赖条款C的定义模型在处理这种嵌套关系时推理链条一长就崩。后来我们在工程侧加了一个条款依赖图的预处理模块先把引用关系抽出来再让模型逐条审核准确率才稳定下来。这个例子说明什么模型能力是有边界的工程侧的价值就是识别边界、绕过边界、或者在边界内把事做成。会议里提到的很多工程实践本质上都是在做这件事。2.3 多模态能力的落地节奏别急着All in多模态是这两年的热词但会议里对多模态的落地节奏给了一个比较冷静的判断视觉理解在特定场景下已经可用但通用多模态Agent还早。什么意思如果你做的是文档OCR加结构化抽取那现在的多模态模型已经能用了准确率比传统OCR方案高不少。但如果你想做通用视觉Agent比如让模型看一个网页截图然后自动操作那还差得远。我试过几个开源的多模态模型做UI自动化效果最好的方案还是截图加坐标回归而不是端到端的视觉理解。原因在于UI元素的位置、层级、交互状态这些信息纯靠视觉特征很难稳定提取。会议里提到的一个思路我觉得很实用多模态能力应该作为Agent的感知模块而不是决策模块。也就是说让模型“看”到信息但“怎么处理”还是交给专门的规划模块。这样既能利用多模态的感知优势又能避免它在复杂决策上的不稳定性。2.4 模型能力边界的工程应对策略既然模型能力有边界工程侧该怎么应对会议里给了几个方向我结合自己的经验展开说说。第一个策略是任务分解。把一个大任务拆成多个小任务每个小任务都在模型的能力舒适区内。比如做数据分析Agent不要让它“分析这份销售数据并给出建议”而是拆成“提取数据”“计算同比环比”“识别异常点”“生成建议文本”四步。每一步的输入输出都明确模型出错的概率就低很多。第二个策略是外部记忆。模型上下文有限那就把历史信息存到外部向量库或结构化数据库里需要的时候再检索回来。这个思路现在很成熟了但关键在于检索的时机和粒度。我见过很多项目把什么都往向量库里塞结果检索出来的内容噪音太大反而干扰模型判断。会议里提了一个原则只存模型自己产生不了的信息比如用户的历史操作、业务规则、实时数据。模型自己能推理出来的常识性内容没必要存。第三个策略是验证闭环。模型输出之后加一层规则校验或小模型校验。比如代码生成之后跑一遍单元测试SQL生成之后做一次语法检查。这层校验不需要很复杂但能拦住大部分低级错误。我在项目里加了一个简单的JSON schema校验就把Agent的工具调用失败率从15%降到了3%以下。3. Agent工程化从Demo到生产环境的距离3.1 Agent不是“模型加工具”而是一套执行系统很多人对Agent的理解还停留在“让模型调用API”这个层面。会议里明确反对这种简化Agent是一套完整的执行系统模型只是其中的决策组件。一个生产可用的Agent至少包含五个模块任务规划、工具调用、状态管理、错误恢复、结果验证。缺了任何一个Agent在真实场景里都会出问题。我拿自己做过的一个客服Agent举例。最初版本就是简单的“用户提问、模型判断意图、调用对应API、返回结果”。Demo阶段看起来很美但上线第一天就崩了。问题出在状态管理上用户问了一个多轮问题第一轮问退货政策第二轮问具体订单能不能退第三轮问退款多久到账。模型在第二轮的时候还记得订单号到第三轮就忘了因为它只看到了当前轮次的输入。后来我们加了一个会话状态机把关键实体订单号、用户ID、问题类型显式存下来每轮都注入到模型上下文里问题才解决。这个经历让我深刻理解了一件事Agent的难点不在模型调用而在状态流转和异常处理。模型调用谁都会写但让Agent在十轮对话后还能记住关键信息、在API超时后能自动重试、在工具返回异常时能降级处理这些才是工程化的门槛。3.2 任务规划模块的设计要点任务规划是Agent的大脑决定了“先做什么、后做什么、什么时候停”。会议里提到了几种规划模式我结合实际项目说说各自的适用场景。第一种是ReAct模式也就是“推理加行动”交替进行。模型先输出一段推理说明当前该做什么然后调用工具观察结果再推理下一步。这种模式适合探索性任务比如信息检索、故障排查。优点是灵活缺点是容易陷入循环模型可能反复调用同一个工具。我在项目里加了一个调用次数上限和重复调用检测超过阈值就强制切换策略。第二种是Plan-and-Execute模式先让模型生成一个完整的执行计划然后按计划逐步执行。这种模式适合流程明确的任务比如数据ETL、报告生成。优点是效率高一次规划多次执行缺点是计划一旦有误后面全错。我的经验是计划生成之后加一步人工确认或规则校验确认没问题再执行。第三种是分层规划把任务拆成高层目标和低层动作高层用大模型规划低层用小模型或规则执行。这种模式适合复杂但重复性高的任务比如自动化测试、批量数据处理。优点是成本低、稳定性好缺点是需要提前定义好动作空间。会议里没有说哪种模式最好因为规划模式的选择取决于任务特性。我的建议是先用ReAct快速验证可行性跑通之后如果发现效率不够再考虑Plan-and-Execute或分层规划。3.3 工具调用的稳定性保障工具调用是Agent和外部世界交互的接口也是最容易出问题的地方。会议里列了几个常见的坑我一个个说。第一个坑是参数格式错误。模型生成的JSON有时候会多一个逗号、少一个引号或者把数字写成字符串。这种错误在Demo阶段可能被忽略但在生产环境就是致命伤。我的做法是在工具调用外面包一层参数校验用JSON schema严格检查不通过就返回错误信息让模型重试。重试两次还不行就降级到人工处理。第二个坑是超时和重试。外部API不可能100%可用网络抖动、服务限流、下游故障都会导致调用失败。Agent必须有一套超时控制和重试策略。我的经验是读操作可以重试三次写操作最多重试一次避免重复写入重试间隔用指数退避。如果重试都失败就把任务挂起记录状态等人工介入。第三个坑是工具返回结果的解析。有些API返回的是嵌套很深的JSON模型直接解析容易出错。我的做法是在工具层做一次扁平化处理把关键字段抽出来用自然语言描述给模型。比如不要给模型一个完整的订单对象而是告诉它“订单号12345状态已发货预计三天后送达”。这样模型的理解准确率会高很多。3.4 错误恢复与降级策略Agent在真实环境里跑出错是常态。会议里强调了一个原则错误恢复不是事后补救而是设计时就该考虑的一等公民。我把它拆成三个层次。第一层是模型层面的恢复。模型输出格式错误、推理逻辑矛盾、工具调用参数不对这些都可以通过重新提示来恢复。关键是要把错误信息清晰地反馈给模型让它知道哪里错了。我通常会把错误类型、错误位置、期望格式一起塞回上下文模型修正的成功率能到80%以上。第二层是任务层面的恢复。如果某个子任务反复失败Agent应该能跳过它或者换一种方式完成。比如一个数据抓取任务某个页面一直超时Agent可以标记该页面为“暂时不可用”继续处理其他页面最后汇总时说明哪些数据缺失。这种部分成功的策略比整个任务失败要好得多。第三层是系统层面的降级。如果模型服务本身不可用Agent应该能切换到备用模型或规则引擎。我在项目里配了一个轻量级的规则引擎作为兜底处理最常见的几类请求。虽然效果不如模型但至少保证服务不中断。会议里有一句话我印象很深Agent的可靠性不是靠模型变强解决的而是靠工程手段堆出来的。这话听起来有点悲观但确实是实情。我在生产环境跑Agent的经验是模型能力决定上限工程能力决定下限而用户感知到的往往是下限。4. 开源策略与生态构建开什么、怎么开、什么时候开4.1 开源不是目的而是手段会议里对开源的讨论很务实没有太多情怀更多是战略层面的考量。核心观点是开源是为了构建生态生态是为了分摊成本、加速迭代、建立标准。如果一个项目开源之后没有形成生态那开源就是失败的。我观察过几个成功的开源大模型项目它们的共同点是开源核心能力但保留工程化服务和商业支持。比如模型权重开源但推理优化、部署工具、监控运维这些“脏活累活”是商业化的。这种策略的好处是开发者可以自由使用模型但企业客户想要稳定可靠的服务还是得找官方或合作伙伴。会议里提到一个判断开源模型的竞争力不在于参数规模而在于工程配套。一个7B的模型如果配套了完善的微调工具、部署方案、评估体系它的实际可用性可能超过一个70B但只有权重文件的模型。我在选型时深有体会拿一个开源模型过来光是跑通推理就要折腾半天更别说微调和部署了。后来我优先选那些有完整工具链和活跃社区的模型哪怕参数小一点综合成本反而更低。4.2 开源项目的参与方式与贡献路径如果你是一个开发者想参与开源大模型项目会议里给了几条路径。我结合自己的经验展开说说。第一条路径是使用和反馈。这是门槛最低的参与方式。你不需要懂模型架构只需要在实际项目中使用它然后把遇到的问题、需要的功能、发现的bug反馈给社区。很多开源项目的迭代方向就是被用户反馈驱动的。我参与过的一个项目就是因为用户反复提“需要更好的中文支持”后来专门优化了中文tokenizer。第二条路径是工具和插件开发。开源模型本身可能只提供推理能力但围绕它的工具链——比如可视化界面、部署脚本、监控面板、微调工具——往往是社区贡献的。如果你擅长工程侧这是最容易做出可见贡献的方向。我贡献过一个Ollama的WebUI中文适配虽然代码量不大但被很多国内开发者用到反馈很好。第三条路径是模型微调和领域适配。如果你有特定领域的数据和场景可以基于开源模型做微调然后把微调后的模型或微调方法开源出来。这种贡献的价值很高因为它证明了模型在真实场景中的可用性。会议里提到领域微调是开源模型落地的最短路径因为通用能力已经由基础模型解决了领域知识才是差异化所在。第四条路径是文档和教程。这听起来不起眼但实际非常重要。很多开源项目功能很强但文档写得一塌糊涂新用户根本不知道怎么上手。如果你能写一篇清晰的入门教程、录制一个实操视频、整理一份常见问题清单对社区的贡献不亚于写代码。我自己在选型时文档质量往往是决定用不用的关键因素。4.3 开源协作中的常见摩擦与解决思路开源协作不是请客吃饭摩擦是常态。会议里没有回避这个问题我结合自己的经历说说常见的几类摩擦和应对方式。第一类是方向分歧。社区里有人想加新功能有人想优化性能有人想修bug优先级怎么排我的经验是看项目维护者的路线图。如果维护者有清晰的规划那就跟着走如果没有那就先做自己最需要的做成PR再讨论。不要一上来就提大重构维护者大概率不会理你。第二类是代码风格冲突。不同背景的开发者写出来的代码风格差异很大PR被拒的原因经常是“风格不一致”。我的做法是提交PR之前先读一遍项目的贡献指南看看有没有代码规范、测试要求、提交信息格式。如果没有就模仿现有代码的风格。这能省掉很多来回扯皮的时间。第三类是沟通效率问题。开源项目大多是异步沟通一个issue可能几天才有人回。我的经验是提问要具体、可复现、有上下文。不要只说“这个功能不work”而是说“我在什么环境下、执行了什么命令、期望什么结果、实际什么结果、错误日志是什么”。这样维护者能快速定位问题回复的概率也高很多。第四类是商业化与开源的平衡。有些项目一开始很开放后来慢慢把核心功能闭源了社区会有被背叛的感觉。会议里提到开源协议的选择很关键。Apache 2.0、MIT这类宽松协议对商业友好但保护不了核心利益GPL这类传染性协议能保证衍生作品也开源但会吓跑商业用户。我的建议是根据项目定位选协议选了就不要轻易改。频繁变更协议对社区信任的伤害很大。4.4 从开源项目到生产系统的距离很多开发者有一个误区开源模型拿过来就能用。实际上从开源项目到生产系统中间隔着一条巨大的工程鸿沟。会议里列了几个必须补齐的环节我一个个说。第一个环节是性能优化。开源模型通常只保证正确性不保证性能。在生产环境里你需要做量化、蒸馏、推理加速、批处理优化。我做过一个对比同一个7B模型原始版本在单卡上每秒处理3个请求经过量化和推理优化之后能到每秒20个请求。这个差距直接决定了能不能扛住真实流量。第二个环节是部署和运维。开源项目一般只给一个推理脚本但生产环境需要容器化、自动扩缩容、健康检查、日志监控、版本管理。这些都需要自己搭。我的经验是优先选那些有Kubernetes部署方案的项目能省掉大量运维工作。第三个环节是数据安全和合规。开源模型跑在自己的服务器上数据不出域这是优势。但也要考虑模型输出内容的审核、用户数据的隔离、访问权限的控制。我在项目里加了一层输出过滤把敏感信息和不合适的内容拦掉虽然增加了延迟但合规风险降了很多。第四个环节是评估和迭代。开源模型更新了你怎么知道新版本比旧版本好需要一套自动化评估体系覆盖准确率、延迟、成本、稳定性等维度。我通常会在上线前跑一轮回归测试对比新旧版本的关键指标确认没有退化再切换。会议里有一句话总结得很到位开源模型是原材料生产系统是成品中间需要大量的加工工序。谁掌握了这些工序谁就能把开源模型的价值真正释放出来。5. AGI路径判断从业者该把精力押在哪里5.1 AGI的阶段性特征哪些能力已经具备会议里对AGI的讨论没有停留在哲学层面而是拆成了具体的能力维度。我把它整理成一个对照表方便大家判断当前技术所处的位置。能力维度当前状态工程可用性关键瓶颈语言理解与生成接近人类水平高长文本一致性知识检索与问答超过普通人高时效性与准确性代码生成与调试中级工程师水平中高复杂系统设计多步推理有限场景可用中长链条稳定性环境交互与操作初级水平低感知与决策耦合自主学习与进化几乎不具备极低架构层面缺失从表里可以看出语言和知识层面的能力已经相当成熟推理和交互层面还在早期自主学习基本是空白。这意味着当前阶段做AI应用应该优先利用成熟能力谨慎对待早期能力不要碰空白能力。我在项目里的策略是能用检索解决的不用推理能用规则解决的不用模型能用单步解决的不用多步。每引入一个不成熟的能力就多一个不稳定因素。会议里提到的“工程侧要做的不是追求模型多强而是把模型能力用到极致”说的就是这个意思。5.2 推理能力的突破方向架构创新还是工程堆叠推理能力是通往AGI的核心关卡。会议里讨论了一个关键问题推理能力的提升是靠架构创新还是靠工程堆叠目前的共识是两者都需要但工程堆叠的短期收益更明显。架构创新方面思维链、树搜索、自我反思这些技术已经在用了但效果有天花板。模型再怎么会反思它的知识边界和推理深度还是受限于训练数据。工程堆叠方面外部工具、符号推理、知识图谱这些手段可以补上模型的短板。比如数学计算模型自己算容易错但调用计算器就稳了逻辑推理模型容易绕晕但用Prolog或规则引擎就清晰了。我的判断是未来两三年推理能力的提升主要靠工程堆叠架构创新是长期变量。所以从业者应该把精力放在怎么把外部工具和模型能力无缝衔接上而不是等一个“更聪明的模型”来解决所有问题。会议里提到的一个方向我觉得很务实把推理过程显式化、可干预化。也就是说不要指望模型在黑盒里完成所有推理而是把推理步骤拆出来每一步都可以检查、修正、替换。这样即使模型某一步错了也不会导致整个任务失败。5.3 Agent作为AGI的过渡形态定位与局限会议里给Agent的定位很清晰Agent是AGI的过渡形态不是终点。它能在特定场景下完成复杂任务但离通用智能还有本质差距。这个判断很重要因为它决定了我们应该怎么设计Agent系统。Agent的局限主要有三个。第一是泛化能力有限。一个在客服场景调好的Agent换到销售场景可能完全不能用因为工具集、对话流程、异常处理都不一样。第二是学习能力缺失。Agent不会从失败中自动学习每次遇到新问题都需要人工调整提示词或工具配置。第三是成本结构不优。复杂Agent的推理成本很高因为要反复调用模型做规划、决策、验证。一个任务跑下来token消耗可能是简单问答的几十倍。但Agent的价值也很明显它把大模型的能力从“问答”扩展到了“做事”。问答只能提供信息做事才能创造价值。会议里提到Agent的商业化路径比通用AGI更清晰因为它的价值可以直接用任务完成率、人工替代率来衡量。我在项目里做Agent客户最关心的不是“它有多智能”而是“它能帮我省多少人”。这个指标很实在也更容易验证。5.4 从业者的精力分配建议基于以上判断会议里给从业者提了几条精力分配的建议。我结合自己的经验把它整理成可操作的优先级。第一优先级是工程能力。包括Agent框架、工具调用、状态管理、错误恢复、评估体系。这些能力不依赖模型突破现在就能积累而且越积累越值钱。我在招聘时最看重的就是候选人在这些方面的实战经验而不是“用过哪个模型”。第二优先级是领域知识。大模型是通用的但应用是垂直的。你在某个领域的知识越深越能设计出贴合场景的Agent。比如做医疗Agent你得懂病历结构、诊疗流程、合规要求做金融Agent你得懂交易规则、风控逻辑、监管政策。这些知识模型给不了你只能自己积累。第三优先级是模型理解。你不需要会训练模型但需要理解模型的能力边界、提示词工程、微调方法、评估指标。这样在选型和调优时才能做出合理判断。我见过一些团队模型选错了后面怎么调都效果不好根源就是一开始没理解模型特性。第四优先级是架构创新。这是长期变量适合有研究能力的团队。如果你在做应用层不建议把精力押在这里因为投入产出比不确定。但如果你在做基础设施或平台层那架构创新是核心竞争力。会议里有一句话我记了很久AGI不是等来的是在解决具体问题的过程中长出来的。每个Agent项目、每次工程优化、每个领域适配都是在为AGI铺路。从业者不需要焦虑“AGI什么时候来”只需要确保自己在这个过程里持续创造价值。6. 实操避坑我在Agent项目里踩过的那些坑6.1 提示词工程的三个反直觉经验提示词工程听起来简单但实际做起来坑很多。我分享三个反直觉的经验。第一个经验是提示词不是越长越好。很多人喜欢把各种规则、示例、约束都塞进系统提示词结果模型反而抓不住重点。我的做法是分层管理核心规则放系统提示词任务相关放用户提示词示例按需动态注入。这样模型每次看到的上下文都是精简的注意力更集中。第二个经验是少用否定句。你告诉模型“不要编造信息”它可能反而更容易编造因为“编造”这个词被激活了。更好的方式是正面引导“如果不知道答案请回复‘我需要更多信息’”。这样模型有一个明确的替代行为而不是被禁止某个行为。第三个经验是示例的质量比数量重要。给模型三个精心设计的示例比给十个随便写的示例效果好得多。示例要覆盖典型情况、边界情况、错误情况三类。我在做工具调用时会专门放一个“参数缺失”的示例教模型怎么追问用户效果很好。6.2 上下文管理的实战技巧上下文管理是Agent工程里最容易被低估的环节。我踩过的坑包括上下文太长导致模型注意力分散、上下文太短导致信息丢失、上下文顺序不对导致模型理解错误。我的解决方案是分层上下文。把上下文分成四层系统层角色、规则、能力说明、会话层历史对话摘要、任务层当前任务的目标、状态、已执行步骤、即时层当前轮次的输入和工具返回。每层有不同的更新频率和长度限制。系统层基本不变会话层定期压缩任务层每步更新即时层每轮清空。压缩会话层的时候我不用简单的截断而是让模型自己生成摘要。提示词大概是“请用三句话总结以上对话的关键信息包括用户身份、核心诉求、已确认的事实。”这样压缩后的信息密度更高模型后续理解也更准。6.3 工具设计的五个原则工具是Agent的手脚设计得好不好直接决定Agent能不能干活。我总结了五个原则。原则一一个工具只做一件事。不要设计“万能工具”参数一大堆模型根本记不住。每个工具的功能要单一、明确、可预测。原则二参数名要自解释。不要用arg1、param2这种名字要用order_id、start_date这种一看就懂的。模型对参数名的理解直接影响调用准确率。原则三返回值要结构化且精简。不要返回一大坨JSON把关键字段抽出来用清晰的格式返回。我通常返回一个包含status、data、message三个字段的对象模型处理起来很稳定。原则四错误信息要可操作。工具调用失败时不要只返回“error”要返回“参数order_id格式错误应为10位数字”。这样模型知道怎么修正。原则五工具数量要克制。Agent能用的工具不是越多越好。我做过测试工具超过15个之后模型的选择准确率明显下降。如果确实需要很多工具就做工具分组先让模型选组再选具体工具。6.4 评估体系的搭建方法没有评估体系的Agent项目就是盲人摸象。我搭建评估体系的方法是三层评估。第一层是单元测试。针对每个工具、每个提示词模板、每个规划逻辑写独立的测试用例。这层测试跑得快适合开发阶段频繁运行。第二层是场景测试。模拟真实用户的多轮对话覆盖典型场景和边界场景。这层测试需要人工设计用例但能发现单元测试发现不了的问题比如上下文丢失、状态混乱。第三层是线上评估。在真实流量里埋点收集任务完成率、用户满意度、平均轮次、异常率等指标。这层测试最真实但反馈周期长。我的做法是灰度发布先放5%的流量观察一周再逐步扩大。评估指标方面我最关注三个任务完成率用户的问题有没有被解决、平均交互轮次效率高不高、异常恢复率出错后能不能自己修好。这三个指标能覆盖大部分质量问题。6.5 成本控制的几个狠招Agent的token消耗比普通问答高很多成本控制是绕不开的问题。我试过几个有效的办法。第一个办法是模型分级。简单任务用小模型复杂任务用大模型。判断任务复杂度可以用规则也可以用一个小分类模型。我在项目里把任务分成三档分别用7B、13B、70B的模型处理成本降了60%以上。第二个办法是缓存。很多请求是重复的比如“退货政策是什么”这种常见问题。我把高频问题的答案缓存起来命中缓存直接返回不走模型。缓存命中率能到30%左右。第三个办法是上下文压缩。前面提到的分层上下文和摘要压缩不仅提升效果也直接降低token消耗。我做过对比压缩后的上下文长度平均减少40%效果反而更好。第四个办法是提前终止。Agent执行过程中如果已经能确定结果就提前结束不要跑完整个流程。比如用户问“订单12345的状态”工具返回“已发货”之后就不需要再调用其他工具了。我在规划模块里加了一个充分性判断满足条件就停。这些办法组合起来能把Agent的运营成本控制在可接受范围内。会议里提到成本是Agent商业化的关键变量技术再好成本降不下来客户也不会买单。7. 从这份整理稿里带走的几个判断7.1 短期一年内值得投入的方向基于会议内容和我的实践经验短期值得投入的方向有三个。第一是Agent工程框架包括状态管理、工具调用、错误恢复、评估体系。这些能力不依赖模型突破现在做就能见效。第二是领域微调针对特定场景优化模型提升准确率和稳定性。第三是部署和运维工具链让开源模型更容易在生产环境落地。这三个方向的共同点是不赌模型能力突变而是把现有能力用到极致。我在项目里的体会是把工程做扎实比等一个更强的模型更靠谱。7.2 中期两到三年需要关注的变化中期需要关注的变化包括推理能力的工程化突破、多模态Agent的成熟、开源生态的进一步分化。推理能力方面我预计会有更多“模型加符号推理”的混合方案出现。多模态方面视觉感知会先成熟视觉决策还需要时间。开源生态方面可能会出现几个主流的技术栈选型会变得更清晰。7.3 长期三年以上的不确定性长期的不确定性主要来自架构层面的创新。如果出现新的模型架构能从根本上解决长链条推理和自主学习的问题那整个工程侧的重心都会转移。但在那之前工程能力仍然是核心竞争力。我的建议是保持对架构创新的关注但不要把业务押在不确定的技术突破上。7.4 给不同角色的行动建议如果你是开发者建议深入一个Agent框架把它用到极致同时积累领域知识。如果你是产品经理建议多跟工程团队聊理解技术边界不要设计超出模型能力的交互。如果你是技术负责人建议建立评估体系用数据驱动选型和优化不要凭感觉做决策。如果你是创业者建议从垂直场景切入用Agent解决具体问题不要一上来就做通用平台。这份整理稿的价值不在于它给了什么标准答案而在于它把问题定义清楚了。剩下的就是每个从业者根据自己的场景去实践、去踩坑、去总结。我在实际项目里最大的体会是大模型和Agent的落地技术只占三成工程和场景占七成。把后两者做好技术价值才能释放出来。