今天早上看到不少AI日报在转发这三个消息：OpenAI在数学推理上又拿下一个标志性进展、MCP协议正在把各家智能体生态拧成一股绳、AI对软件工程成本结构的改写已经从"自动写代码"蔓延到整个预算模型。单看任何一条都像日常小进展，合在一起却指向同一个判断——2026年下半年的AI竞争，已经从"能不能做"进入"划不划算做"的阶段。

这篇文章写给三类人：做AI应用和智能体的工程师，想知道该把精力押在推理能力、协议还是工程上；传统软件团队，想搞清楚成本重构之后自己的位置在哪；以及需要拍板投钱的决策者，想知道该往哪个环节加预算。我不堆概念，只讲我用实际项目验证过的判断。

1. 三件大事各走各路，但指向同一个拐点

1.1 表面是三份独立新闻，里子是同一条链条

把这三件事看成孤立的"今天有什么新消息"，很容易看完就忘。但把时间轴拉长到半年再看，它们其实是同一个拐点的三个侧面。

OpenAI的数学突破，代表的是模型能力的上限还在被推高。数学一直是公认的硬骨头，因为它在逻辑严密性上几乎没有模糊地带，一个证明错一步就全错，一道题对就是对、错就是错。能在这种任务上持续突破，说明模型在长链条推理上的可靠性还在往前走。这件事的意义不只在实验室里，它决定了智能体在真实业务中能不能处理那些需要多步推导的任务。能力曲线往上走，才是后面所有工程化叙事的前提。

MCP协议统一智能体生态，解决的是"能力有了，怎么让所有工具都愿意被模型调用"的基础设施问题。以前每家智能体厂商都在搞自己的工具接入方式，你接了一个平台的生态，到另一个平台又得重写一套。MCP做的事情跟USB-C统一充电接口很相似——定义一套标准插口，让模型宿主、工具服务方、业务应用三方不用互相迁就。协议层的统一看起来不像模型突破那样炫目，但它直接决定智能体生态的密度：标准越统一，愿意接进来的工具越多，智能体才真正从聊天框里走出来干活。

AI重写软件工程成本结构，则是前两者在商业世界的最终体现。能力和基础设施到位之后，变化就开始冲击真金白银的软件研发预算。过去一个软件项目里写代码往往是最贵的一环，现在AI把编码的边际成本打到极低，钱和时间并没有因此消失，而是流向了需求描述、验证评测、遗留系统处理这些以前不太起眼的环节。成本结构一翻盘，团队配置和岗位要求都得跟着翻盘。

1.2 今天的读者里，谁最需要调整节奏

先对号入座，再看后面几章会更有效。

做AI应用和智能体的工程师，你们的核心议题是：模型推理能力升级之后，我的应用架构需不需要跟着改？MCP标准化之后，我原来给每个工具写私有适配器的做法是不是该淘汰了？你们手里握着的是最直接的落地压力。

传统软件团队里的开发、测试、项目经理，你们的议题更现实：既然编码成本降了，那团队里多出来的人手应该往哪个方向转？测试和需求分析的比重变大，这是不是意味着工作流程要重新设计？很多团队已经在用AI辅助编程，但预算结构还是老一套，结果就是既花钱买工具又花原有的人力成本，两头烧。

技术决策者最需要想清楚的是投资顺序：是先换更强的模型，还是先建设评测体系和MCP基础设施？今天这三条消息其实提供了同一个答案——模型能力会持续进步，但如果你没有协议层的连接能力，没有验证环节的把关能力，再强的模型也落不了地。

2. OpenAI数学突破：别只盯着分数，看推理范式在换挡

2.1 公开口径里的"数学突破"到底突破了什么

关于这次突破的技术细节，公开渠道能看到的并不算多，但行业里普遍共识是：核心不在于某个单一算法的横空出世，而是"推理时计算加长、强化学习循环、验证器参与"这套组合拳又被验证了一次。

先解释一下什么叫推理时计算。传统大模型回答问题，像人做口算：看一遍题，直接给出答案，速度快但出错率高。推理时计算则是让模型在给出答案之前多花一些时间，生成多步草稿、返工检查、尝试不同路径、甚至自我验证。数学题是最适合这种慢思考的任务，因为每一步对不对有明确标准，错了能定位到具体哪一步，不像开放式写作一样没有唯一答案。

这次能在数学任务上突破，基本可以推断为两个方向的叠加：训练阶段用强化学习让模型在推理链上越走越稳，推理阶段允许模型投入更多计算去搜索和验证。说白了，模型不再追求"第一眼看出答案"，而是学会了"先打草稿，再检查，再交卷"。对应用层来说，这意味着一个重要的趋势判断：未来很长一段时间，模型智能的提升不再仅仅靠堆参数，把推理阶段的算力预算增大同样能换来实打实的准确率提升。

2.2 为什么数学能成为推理能力最好的试金石

这不是随便挑一个学科当招牌，数学作为AI推理的测试场，有三个独有的优势：

第一是结果可自动判定。一道题对错不需要人类专家费劲评判，程序就能比对，这让训练奖励和评测打分都能自动化、规模化。第二是过程可拆解。数学证明和解题的中间步骤是显式的，模型走哪一步思路错了可以被精准定位，强化学习能针对性地调整策略，而不是只给一个笼统的"对了/错了"信号。第三是难度梯度清晰。从初中竞赛题到IMO级别的问题，难度分布均匀且公认，评测结果跨模型可对比性很强。

这也解释了为什么OpenAI这类头部团队一直死磕数学板块。数学评测不是跟其他模型比分数那么简单，它是检验"模型会不会推理"的标尺。如果连数学这种规则最严密的任务都能稳定拿下，意味着模型在其他复杂任务上至少具备了"多步思考"的基础能力。反过来说，哪天连数学基准都原地踏步了，那说明整个范式也差不多到头了，其他通用任务更不可能有质变。

2.3 泼三盆冷水：数学高分不等于通用智能

我见过不少人，看到一个数学基准刷新就兴奋得不行，觉得通用人工智能马上要来了。每次看到这种反应我都想说，数学是试金石，但试金石测出来的维度很窄，至少有三盆冷水必须泼。

第一盆是基准污染问题。数学题库就那么多，如果训练语料里混入了大量历年竞赛题和公开题解，模型完全可以把题目"背"下来，高分背后的泛化能力存疑。所以现在业界更看重新题表现和跨领域的迁移测试，单看绝对分数没有太大参考价值。

第二盆是领域局限性。数学题有唯一正确答案，但现实世界里的业务任务几乎没有唯一解。一个客服工单怎么算处理得好，一条营销文案怎么算写得好，医疗建议怎么算负责任，这些都没有数学题那样的自动判分器。慢思考范式在数学里好使，迁移到模糊任务上就需要额外的评测设计和人工参与，成本和复杂度都会上一个台阶。

第三盆是资源账单问题。推理时计算不是免费的，一次深度思考消耗的算力可能是快速模式的几十倍。对科研团队来说，多花算力去刷一个高分很值；但对商业落地来说，准确率提升10%却要付出5到10倍的推理成本，很多场景根本不划算。这也是为什么我说今天这三条新闻是一个整体——模型能力再强，最终都要过成本结构这一关。

2.4 对应用层团队的四个可执行判断

不聊纯技术，站在应用层最关心的视角，我从这个突破里读出了四个可以直接落地的判断。

第一个判断：评估模型别只看基准分数，要看"固定成本下的表现"。我现在给团队定评估方案，一定会加一条：在限定推理预算（比如最大思考轮次、单任务超时时间）下跑测试集，比较每个模型的通过率和单次成本。有时候慢思考模式下的小模型，真的能在同样预算下打出大模型快速模式的效果，这就是实实在在的省钱机会。

第二个判断：复杂业务任务可以主动设计"多候选加验证"的架构。传统做法是把任务一次性抛给模型，现在更好的做法是让模型先生成几个候选答案，再用另一个模型或规则验证器来挑最优。数学突破验证了这招有效，在业务里也可以复刻，只是要把"验证标准"定义清楚。

第三个判断：把可验证的中间结果写进业务流程。数学是对错分明，业务通常不是，但你可以在任务里设计结构化的中间产物，比如关键数据字段、法律条款引用编号、代码测试用例。模型在这些中间环节上的输出可以被规则校验，出错能提前拦截，整体可靠性会好很多。

第四个判断：盯住推理链的可观测性。长推理链模型一旦上线，中间步骤就是调试和追责的抓手。现在开始要求模型在复杂任务里输出思考摘要和关键决策点，这些日志未来就是智能体事故排查、效果优化的第一手材料，别等到出了问题再去补。

3. MCP协议：智能体的"USB-C时刻"，统一的不只是接口

3.1 MCP到底解决了什么：一个接口、一种发现、一条边界

MCP的全称是Model Context Protocol，本质上是一套让AI模型与外部工具、数据源进行标准交互的协议。它源自Anthropic开源的项目，现在已经成了智能体生态里事实上的连接标准。你要理解它，抓住三个层次就够了。

第一层是接口统一。没有MCP之前，每接入一个工具就要写一套私有对接：查数据库是一种方式，调浏览器是另一种方式，控制设计软件又是完全不同的方式。MCP定义了一套基于JSON-RPC 2.0的标准消息格式，客户端和服务端怎么握手、怎么列工具、怎么调用工具，全部按同一套规矩来。开发一次，处处复用。

第二层是能力发现。协议里定义了tools/list这类元信息接口，模型客户端在运行时可以去查询"当前有哪些工具可用、每个工具的入参是什么、描述是什么"。模型像拿到一张菜单，能自己决定该调用哪个工具。这和以前在代码里死板地硬编码工具调用完全是两个时代的体验。

第三层是权限边界。MCP允许你在服务端声明能力范围，比如哪些工具只读、哪些可写、哪些需要授权确认。智能体拥有了"手"之后，最危险的就是手伸得太长，MCP给了你在连接层就约束行为边界的手段。

做一个类比你立刻就能懂：MCP就是智能体的USB-C标准。以前厂商各做各的私有接口，我的充电器插不进你的手机；现在统一了协议，任何宿主应用都能同一个姿势接入任何工具服务。生态繁荣的前提是接口标准统一，MCP就是在给智能体工具生态装上那条标准线。

3.2 从社区热点看MCP的真实落地：从浏览器到安全测试到FPGA

判断一个协议是不是真趋势，别看官方新闻稿，看社区里大家在搜什么、在折腾什么。

最近一段时间被反复提起的Playwright MCP、Chrome DevTools MCP，说明很多团队已经在让AI直接控制浏览器操作页面、抓取DOM、跑前端自动化。这不再是"让AI写一段代码给你自己执行"，而是AI自己能打开浏览器、点击按钮、读取页面反馈、再根据反馈决定下一步动作。做网页自动化的人应该能感受到这是质变。

安全测试圈子的Burp Suite MCP也很有代表性。安全测试人员让AI直接操作Burp Suite去发请求、分析响应、扫描漏洞，把原来需要人在GUI里点点点的环节交给智能体。这样做带来的好处是工具使用门槛大幅降低，但风险也随之而来——一个权限没配好的MCP Server直接把扫描器暴露给内网，后果不堪设想。我后面会专门讲这个坑。

设计工具领域同样在接入，Unity这类游戏引擎有了MCP，芯片设计里的Vivado也有社区版的MCP实现。说白了，所有"原本需要专门学会一个复杂工具才能干活"的场景，都在被MCP改造成"AI拿着这个工具的遥控器干活，人类只需要盯着决策质量"。企业内部甚至开始把MCP做成交付项，比如RuoYi-Vue-Pro这类框架已经出现合并MCP功能的版本，后台系统的表单、权限、数据查询都可以开放给AI调用，MCP已经走进企业软件的标准配置。

这些热点串起来看，你就明白为什么我说MCP统一的不只是接口——它统一的是智能体与物理世界、数字世界交互的方式。

3.3 搭一个MCP Server前，你需要想清楚的六件事

如果你准备动手接MCP，我有六条实操清单，都是踩过坑之后总结出来的，比官方文档更接近实战。

第一，选SDK别自己造轮子。MCP官方提供TypeScript和Python SDK，协议握手细节都封装好了，直接用SDK能省掉大量排查协议错误的痛苦。除非你有强理由，不要用纯HTTP裸写协议，除非你想体验一把和版本兼容性搏斗的酸爽。

第二，传输方式按场景选。本地命令行工具、单机Agent用stdio传输，启动一个子进程通信，简单高效。远程服务、多人共用、Web端Agent用HTTP方式，现在新版协议走Streamable HTTP，比旧版SSE更省事也更稳定。远程一定要记得把鉴权放在Authorization头里，别裸奔在公网上。

第三，优先实现工具能力。MCP协议里有三类能力：Tools（可调用工具）、Resources（可读取的资源）、Prompts（提示词模板）。对大多数场景来说，Tools是核心，Rescoures和Prompts可以后期再加。先把工具列表做扎实，模型才有可操作的抓手。

第四，工具命名和描述要规范到能当文档用。模型完全靠工具的自然语言描述来决定"什么时候该调用哪个工具"，描述写得含糊，误调用率就居高不下。我见过一个数据查询工具描述里没写清楚"仅当用户明确要求查询时才调用"，结果模型在闲聊时也疯狂触发查询，浪费了大量成本和额度。正确写法是明确边界："仅当用户询问具体数据时才调用，需提供表名和筛选条件，否则不要调用。"

第五，返回体必须结构化并预留截断。工具返回给模型的内容会直接占上下文窗口，一个查询接口返回几万行JSON，整个窗口直接被冲爆。一定要在服务端做分页、截断、摘要化，保障返回体总是精简、结构化的数据。

第六，高危工具必须做幂等和二次确认。delete类、发送类、写操作类工具，智能体稍微判断出错就可能触发不可逆操作。服务端要实现幂等令牌，同一个请求重试不产生重复操作，客户端在调用高危工具前要强制模型先输出"确认执行"的意图。拿钱出去的动作，永远要留一道人工闸门。

3.4 协议没问题，但工程会教你做人

MCP协议本身很优雅，但我实际接入下来发现，大部分事故都不是协议问题，而是工程粗糙。挑几个典型场景讲讲。

最常遇到的是上下文被工具返回撑爆。我第一次接一个表格查询工具，工具返回了全量数据，Agent在接下来的所有对话里都背着这几十万字的包袱，回答速度越来越慢、费用越来越高。后来我加了限制：默认只返回前50行加总计信息，模型需要更多细节时再按页拉取。这个问题立刻缓解了七八成。

第二个高频坑是Agent反复调用有副作用的工具。模型没搞懂工具边界的时候，会对同一个写操作重试好几次。给服务端加上幂等控制之后，同一个任务即使被模型调用三次，真正执行的只有一次，这类事故才被止住。

第三个坑是权限范围想当然。我给内部做过一个MCP网关，刚开始图省事，一个服务端连了多个内部系统，结果任何一个工具被模型误调用都会波及一片。后来拆成细粒度服务端，每个服务端只暴露必要工具，权限模型立刻清晰了，排查问题也更快。

还有一个兼容性细节容易翻车：Server和Client的协议版本不一致。老版本SSE客户端去连新版Streamable HTTP服务端，会出现连接闪断和握手失败。升级的时候千万不要只升服务端不升客户端，两边SDK版本得一起锁。经验法则：把MCP相关依赖全部锁死在一个大版本下，别用latest裸奔。

4. AI重写软件工程成本结构：钱没消失，只是在搬家

4.1 从"写代码最贵"到"想清楚和验证最贵"：成本曲线的翻转

传统软件工程里，成本大致分布在需求分析、系统设计、编码实现、测试部署、后期维护这几个环节，其中编码和单元测试往往占掉最大一块。这也好理解，以前一行行手写代码是最需要人力、时间也最不可压缩的。

AI编程工具普及以后，最大的变化是这一段成本直接被压扁了。尤其以任务级Agent为代表的新工具出来之后，从"自然语言描述需求"到"生成可运行的代码、测试、提交记录"之间的过程，边际成本降到了几乎可以忽略的程度。但注意，成本没有消失，它只是搬了家，去了三个以前被低估的地方。

第一个新成本中心是需求规格化。模型不像人那样能从一句"帮我把用户管理做好"里脑补出一整套逻辑，它需要明确到字段、状态流转、异常边界、验收标准。把模糊业务需求翻译成可执行的任务描述，这个工作比过去写详细设计文档还要吃功夫。我见过好几家团队，用上AI工具后效率反而没提升，就是因为需求描述环节花的时间比以前多得多，需求讲不清，AI就在错误的路上越跑越远。

第二个新成本中心是验证和评测。AI能产出大量代码，但产出的每行代码都需要被验证正确性。没有自动化测试体系和评测集兜底，AI生成的代码越多，线上事故的炸弹就越多。这个环节过去是团队里最容易被压缩的，现在直接变成生死线。

第三个新成本中心是遗留系统迁移。老系统的技术债不会因为AI强大就自动消失，把历史代码迁移到AI更易维护的新架构上，过程比从零写一遍还痛苦，因为你要理解老代码的隐性业务逻辑。AI能帮你写新代码，但"业务逻辑在旧代码里到底是怎么跑的"这个理解成本，一分钱都省不掉。

4.2 Codex CLI式任务级Agent：新一代工作流长什么样

我在前几章反复提到任务级Agent，现在展开讲一下它和传统IDE补全的本质区别。以Codex CLI这类命令行Coding Agent为代表，它的交互范式完全变了，从"人在写、AI辅助"变成了"人描述任务、AI在真实环境里执行"。

实际用下来，Codex CLI接到任务后会自己规划步骤、创建修改文件、运行测试、根据测试结果迭代修正，最后整理出改动清单。这已经不是补全几个函数，而是完整的工程执行循环。对使用者来说，角色从"写代码的人"变成了"定义任务和评审结果的人"。

这个转变对成本结构的影响非常直接。以前把一个模块交给初级工程师实现，需要他理解上下文、查文档、写代码、自测、改bug，整套流程以天计。现在同样的任务交给Agent，可能几十分钟就完成了。省下的时间其实应该花在更关键的地方：把任务验收标准想得滴水不漏，以及认真review Agent输出的每个改动。你花在"想清楚"和"审查"上的时间，取代了过去花在"手写"上的时间。

但Agent也不是万能的。它的上限取决于上下文完整度和任务描述的精确度。你让它做个独立的小模块，它很利索；你让它在一个有几百个内部规范、隐性问题、历史包袱的企业系统里干活，它就会迷路。另外一个隐形边界是它对组织内的隐性知识一无所知，比如某个接口为什么不能动，某段逻辑为什么写得很绕，这些只存在于老员工脑子里的信息，Agent永远不知道。

4.3 新工种与新考核：AI测试开发为什么越来越值钱

成本结构一变化，岗位价值跟着重排。最近"AI测试开发"这个词的热度涨得很明显，不是没有原因的。过去测试开发的主要工作是写自动化脚本、维护用例池，现在他们的核心任务变成了设计评测集、构建回归基线、定义Agent任务的通过率阈值、跟踪每次模型或工具升级对整体效果的影响。

听起来和传统QA有点像？其实完全不同。AI系统的评测不是简单断言一个输出值，你要处理多版本模型、多次运行间的随机性、幻觉率、副作用率、成本漂移。一个任务跑五次，三次成功两次失败，是模型问题、工具问题还是描述问题？这需要系统性归因，难度比单测高一个量级。

从我了解的情况看，传统软件工程方法论在这个阶段反而迎来了第二春。很多人觉得"软件工程导论"这类课程没用了，其实恰恰相反，需求分析、范围管理、风险评估这些方法，现在都比以前更需要。只是它们的载体变了：过去面向人和文档，现在面向模型、Agent和评测。那些能把业务需求写成机器可理解的验收标准、能设计出有效评测集的人，才是AI软件时代最稀缺的工程师。

给还在观望的小伙伴一个建议：别死磕提示词技巧，去学评测工程。你给团队搭一条自动化评测流水线，做到每次改动模型、工具、提示词之后都能自动评估效果和成本，单这一项能力就能让你的不可替代性直线上升。

4.4 给团队做一次成本重定位审计

如果你团队正在全面引入AI编程，我建议立刻做一次成本重定位审计，否则很容易出现"买了AI工具、人力没减、需求没变快"的尴尬局面。

我自己给团队做过一个简化版的成本分布表，放在这里供参考。注意这是示意框架，不同团队实际数字差异会很大，但"重心转移"的方向是普遍的。

这个表做完你别急着削减编码岗位人头，重点是做三件事：第一，把节省出来的编码人力往需求分析岗位倾斜，让业务和技术的交接质量提升一个档次；第二，成立一个小型评测小组，哪怕两三个人，专门负责AI产出的效果回归和成本监控；第三，给每个项目设一个"任务描述质量"考核指标，像过去考核代码质量一样考核需求描述的质量，这决定了AI产出的上限。

5. 2026年智能体工程化的分水岭：从概念演示到稳定交付

5.1 "分水岭"共识翻译成工程语言是三根支柱

今年行业里一个被反复引用的判断是：2026年是工业智能体从概念演示走向工程化落地的分水岭。这句话听起来像行业套话，但翻译成工程语言就非常实在了：比赛从"谁的demo更炫"切换到了"谁的SLA更稳、谁能在生产环境扛住流量、谁能做到可观测和可回滚"。

我自己总结工业智能体落地的三根支柱，缺一不可。第一根是可评测，智能体上线前必须定义清楚业务指标，比如任务成功率、平均延迟、失败恢复时间、单任务成本，并且建立能持续跟踪的测试集。没有评测的智能体开发就是盲飞，你根本不知道一次改动是变好了还是变坏了。第二根是可观测，Agent每一步工具调用都要有审计日志，哪个环节调用了什么、输入是什么、输出是什么，都得有迹可循。没有可观测性，智能体出了事故你连排查的起点都找不到。第三根是可回滚，出问题时能快速暂停Agent、回滚到上一个稳定版本，把业务影响压到最小。

这三点听着朴素，但在行业里绝大多数智能体项目其实一个都没做好。大量团队还在用demo思维做生产系统，demo跑通一次就欢呼，完全没想过同一个任务在100次运行里能不能成功95次。分水岭到来的标志，就是甲方开始拿着SLA指标而不是演示视频来做采购决策。

5.2 智能体框架选型：别让第一版就背上自研的包袱

智能体项目越来越多，框架选型的争论也越来越热。市面上有低代码平台型产品（较有代表性的如Dify）、有开源Agent框架、也有完全自研的路子。我的建议向来是：用最小可交付复杂度原则做选型。

对大多数业务场景，先用低代码平台搭建MVP最划算。这类平台通常内置了知识库、工作流编排、对话管理、常用工具集成，业务人员也能上手。好处是交付快、试错成本低，适合先把业务闭环跑通、验证智能体确实能解决真实问题。它的局限在于灵活性，复杂状态机、深度自省类Agent、特别苛刻的权限模型，平台可能兜不住。

自研Agent框架则适合有强工程能力的团队、且业务确实复杂到平台无法支撑时再上。自研的好处是掌控力强，坏处是评测体系、状态管理、日志链路、工具连接全部要自己造。我曾经见过一个团队第一版就选了自研框架，结果做了三个月连"稳定的多轮对话"都没搞定。我的经验法则是：先用平台跑通业务、沉淀出明确的技术瓶颈清单，再决定是否局部自研，而不是一上来就背一个巨大的基础设施包袱。

5.3 智能体工程师面试在变：协议意识取代API调用技巧

最近不少公司在招智能体工程师，我也被拉去面过一些人，明显感觉到这个岗位的能力模型在快速变化。以前面试问得最多的是"你调过哪家大模型的API"，现在这类问题基本被淘汰了，因为API调用本身已经不重要。大家更关心的是你有没有一个Agent项目的完整生命周期经验。

现在高频出现的面试题大概是：你怎么设计Agent的评测集，如何平衡任务成功率和单次成本？你接过的MCP工具里，工具调用失败时的兜底方案是什么？权限失控导致事故后，你的应急预案和复盘做了什么？你的Agent每次会话上下文都是怎么管理的，增长过快时用什么策略？这些问题背后就是我在5.1说的三根支柱：评测、可观测、权限控制。

给正在准备智能体方向面试的朋友一个能力清单：协议意识（MCP、OpenAPI这类标准别停留在听说过）、评测工程能力（至少亲手搭过一套包含测试集和成本监控的评测流水线）、状态机与工作流建模能力（Agent不是死循环，你要能设计它的暂停、恢复、回退）、可观测意识（知道每一步决策怎么留痕）。拥有这四项基本功的人，未来发展空间比单纯钻研提示词的人要大得多。

5.4 最近三个项目里我在用的落地基线

最后分享三个我正在实践的做法，都是用来给智能体工程化的"分水岭"落地的具体手段。

第一个做法是给新项目强制建立评测基线。不管Agent多简单，先做20个典型case加3个困难case的测试集，跑一遍记录通过率、失败原因和单任务成本，然后才开始优化迭代。很多团队说"我们Agent效果不错"，问评测集是什么，答不上来，这就是典型的没有工程化。

第二个做法是凡要调外部工具的Agent必须接MCP并全程留日志。每条tools/call的入参出参都记录下来，既要用于排查事故，也要用它统计每个工具的调用频次、成功率和平均延迟。有一次我就靠着这份日志发现一个工具描述写得不好导致模型反复误触发，改完描述误调用率降了一半。

第三个做法是每周做一次成本回归。我把输出质量、失败重试次数、每任务成本三条数据线一起看，来决策到底是换模型、调提示词还是改工具链路。有时候不是模型不够好，是任务描述本身有歧义导致Agent反复试探，这种情况换更贵的模型纯属浪费预算。

这三个基线都不复杂，但会让你的智能体项目从"靠感觉迭代"变成"靠数据迭代"，这也是我觉得2026年工程化分水岭最真实的含义。

我现在的习惯是给团队定了一个很简单的工作原则：所有AI相关产出，不接评测都算没交付。模型选型、工具接入、提示词优化，都可以通过评测集给出结论。这不是为了流程而流程，是为了让团队的口径统一——在AI能力爆发、协议统一、成本重构这三股力量交汇的节点上，能靠数据做判断的人，才不会被浪潮裹着走。