不谈虚的。2026年AI Agent这个词已经彻底从技术社区的自嗨变成了企业预算表里的常客。我上一阶段接触了十几个不同行业的Agent落地项目最大感受是现在没有人再纠结“Agent能不能做出来”大家纠结的全是另一件事——怎么把准确率从95%磨到99.9%怎么让多步骤任务不失控怎么把一个只会在测试环境里跑通的Demo变成能扛住生产流量的系统。这份报告就是我基于一线实操和同行交流整理出来的2026年版Agent技术发展总结重点说清楚技术栈到底进化到了哪一步哪些能力是包装出来的哪些是真正能打的以及你在落地时大概率会在哪个环节栽跟头。1. 整体设计与定位演进Agent不再是模型而是一套工程系统1.1 核心定位从“会聊天”到“能办事”2026年对Agent最核心的认知转变是大家终于接受了一个事实Agent不等于大模型。一个生产级Agent是模型、控制循环、记忆系统、工具集、权限边界、可观测性这六层结构的组合体。把这个定位想清楚了架构设计就容易了——你不再是“接一个模型API”就完事而是在搭一套具备决策和执行能力的软件系统。我用一个类比来解释这个变化早期做Agent像是招了一个聪明但没工位的实习生你问他什么他能答得头头是道但你让他去把报表整理好发出来他既不知道报表放哪、也不知道该用哪个工具、更不知道做完之后要不要向谁汇报。2026年的Agent工程化就是给这个实习生配齐工位、电脑、流程手册和权限卡。你关注的不是他脑子里有多少知识而是他能不能按照SOP把一件具体的事情办完、办稳。这个定位转变带来一个直接后果Agent项目的主导角色变了。以前是算法工程师和提示词工程师在前线现在是后端工程师、SRE、产品经理、架构师一起进场。我见过不少刚开始做Agent项目的团队第一版用几个Prompt加一个模型API就能跑出很惊艳的Demo但一到生产环境就崩就是因为整个团队把Agent当成模型调优问题而不是当成系统工程问题来处理。1.2 能力边界2026年Agent做得到与做不到的事梳理能力边界比堆砌技术名词更有价值。根据我手上的实测数据和行业基准2026年主流Agent具备这几项已经成熟的能力多步任务规划与执行在明确目标、工具齐备、状态可观测的前提下Agent可以稳定完成20-50步以内的复杂任务链比如从一堆散落文档里提取信息、做清洗去重、生成结构化表格、再按模板输出汇报文件。多工具协同调用一个Agent能同时操作浏览器、数据库接口、内部API、文档处理组件和IM通知渠道任务的拆解和编排可以动态进行。记忆持久化跨会话长期记忆已经工程化Agent能记住项目上下文、用户偏好和历史决策依据。人机协同回退遇到高风险的决策节点比如大额支付、对外发布内容Agent会主动暂停并请求人类确认而不是自作主张执行到底。但也有一些事情2026年的Agent仍然做不好甚至比很多人预期的更慢。第一超长周期完全自主执行仍不可靠数周甚至数月的连续性任务一旦中途环境发生结构性变化比如数据源格式彻底改变Agent的重新规划能力依然偏弱。第二需要“隐性知识”的决策仍然不行比如判断一个含糊表述背后的真实意图、根据人情世故调整沟通方式这类任务目前最好的状态也只是勉强及格。第三多Agent协作的复杂度呈指数级上升3个Agent之间协调还能控制超过5个Agent的“社会性协作”极易出现任务互相等待、信息重复传递、责任归属不清的问题。1.3 影响范围三个正在被重塑的落地场景从行业渗透来看2026年Agent最活跃的战场集中在这三个方向。第一个是企业内部流程自动化。以前说RPA只能搞那些规则固定的重复操作现在Agent可以把“非结构化输入—理解意图—跨系统操作—结果核验—归档通知”这条链路完整跑通直接替代掉过去需要多人协作的中间处理环节。某制造企业的采购部门把供应商资质审核流程交给Agent之后单条审批链路从平均40分钟压缩到6分钟这不是Demo数据是连续跑了三个月的生产数据。第二个是软件研发辅助链条。2026年的Agent在代码生成之外已经延伸到缺陷定位、测试用例生成、变更影响分析、发布风险评估等环节。当前端的Agent和测试Agent配合工作时能形成“写代码—自测—反馈—修复”的闭环。我观察到的行业中位数是在存量系统的维护型需求上Agent辅助能将单需求工时压缩30%左右但这里面水分比较大不同团队的真实水平差距很夸张核心变量在于存量代码的可读性和测试基础的完备程度。第三个是个人知识工作助手。这个场景看着小实际体量极大。笔记整理、会议纪要与行动计划生成、文献综述、数据整理分析、邮件草稿这些低创造性但高频的劳务型工作是目前个人Agent使用频率最高的功能。2026年的明显变化是个人Agent开始具备“主动提醒”能力它不只是在指令下被动响应还会基于日历、邮件流和任务列表主动判断哪些事快到截止日期了、哪些材料还没补齐。2. 核心技术拆解框架、记忆、规划与工具调用的2026年现状2.1 Agent开发框架选型不能只看知名度先说框架。2026年的Agent框架生态已经非常拥挤但仔细看就能发现它们其实分成了几条不同的技术路线选错路线的代价远比选错具体品牌大。第一类是重框架自带完整的运行时、消息总线、状态管理、人机交互界面。这类框架适合做多Agent协作的企业级应用但在我们实测下来它的性能开销和调试复杂度都相当高。如果你只是做一个调用两三个工具的轻量Agent用重框架像是开一辆卡车去送外卖——能送到但成本高、调头难。第二类是轻量编排框架核心只有两件事定义Agent的循环逻辑观察—思考—行动—反思和工具注册机制。这类框架非常灵活适合嵌到现有业务系统里但你需要自己补上记忆管理、权限控制、观测埋点这些外围组件。好处是血统干净、依赖少、排查问题容易。第三类是自己写循环控制逻辑直接调用模型接口只把框架当成一个工具调用层。这在追求极致性能和低延迟的场景里非常常见。内部某量化团队做数据抓取Agent就是这样干的原因很简单他们要精确控制每一步的token消耗和响应格式通用框架的抽象层级反而碍手碍脚。我个人的选型建议是“按团队能力画像来选而不是按热度选”。如果团队里后端工程能力强优先选轻量编排或自研循环如果团队以算法背景为主、工程经验薄弱就老老实实用重框架先把系统跑起来再谈恋爱。另外2026年有个值得注意的趋势框架的差异化开始缩小底层都在做同样几件事所以与其天天关注框架发新版本不如把精力花在应用层设计上。框架只要满足以下三个条件——工具注册灵活、状态可外部化、日志可定制——选哪个都不至于出大问题。2.2 记忆机制短期、长期、工作记忆必须分开设计记忆是Agent区别于普通模型调用的最核心特征也是2026年技术上成熟度提升最明显的模块。但这里说的成熟不是指“能记住聊天记录”这种浅层的东西而是指一套分层记忆架构已经形成行业共识。实践下来记忆系统至少要拆成三个层次。工作记忆对应当前任务执行过程中的中间状态比如正在处理的表格、已经查到的中间结果、当前步骤的上下文。这一层技术含量最低直接把结构化数据放在运行时上下文中就行但有个容易踩的坑很多人把所有中间结果全塞进上下文导致token膨胀单步响应延迟从1秒拖到8秒。正确做法是只保留最相关的状态把不重要的中间结果写到外部存储需要时再检索回来。短期记忆对应单个会话周期内的信息常见实现是滑动窗口加摘要压缩。我的经验是窗口大小不是越大越好要结合任务的实际依赖深度来设。比如做代码库分析这种需要反复对照多个文件的场景窗口太小会频繁丢上下文但大了之后模型的注意力会被稀释该盯住的细节反而盯不住。比较好的方案是做“关键信息漂移检测”——把重要实体、结论、约束条件单独抽出来固化到记忆区而不是依赖上下文窗口硬扛。长期记忆是2026年真正拉开差距的地方。成熟的方案是用向量数据库存语义记忆用关系型数据库存结构化事实两边配合使用。比如Agent记住“这家供应商过去三个月的交付准时率是87%”这种事实就应该进结构化存储而“用户偏好项目周期更短的方案”这种模糊偏好放向量库更合适。不要迷信单一向量库能解决所有记忆问题混合存储的查准率和可解释性都更可靠。2.3 规划能力看似聪明实则脆弱过去两年大家都被“思维链”“自我反思”这类词汇轰炸过。2026年的冷静看法是模型原生的规划能力确实是Agent的上限但它不稳定。同一个模型任务描述清楚时能做出漂亮的步骤拆解任务描述稍带歧义就开始自作聪明。所以工程上的核心思路不是期待模型更聪明而是用外部机制把规划框在安全区内。一个见效明显的外部机制是“规划模板化”。把高频任务的执行路径预先定义成半成品的步骤模板Agent的任务从“自由规划”降级成“从模板中选择并填充参数”。举个例子做一个“周期性数据报表生成”Agent你不用让它每次重新想该干嘛而是给它一个固定的执行蓝图取数—清洗—计算指标—渲染图表—生成文档—发送通知。变体参数只会填充“哪个数据源、哪些指标、发送给谁”规划的确定性一下子就上来了。试用之后成功率可以从82%直接干到96%以上而且排查问题时边界非常清晰。另一个重要机制是“反思与重规划”的触发条件显式化。不要等Agent自己意识到错误而是设置一堆明确的中间检查点比如某步骤执行结果与预期类型不符、某工具调用连续报错超过两次、任务时间预算已用掉60%但进度不足40%满足任一条件就强制触发重规划或向人工求助。这个设计本质上是对Agent的不信任显式建模结果反而更可靠。2.4 工具调用从“能调”到“会调”工具调用是Agent真正产生行动价值的通道。2026年的能力进步主要体现在工具定义的标准化和调用鲁棒性上。先说标准化。业界基本形成了一套工具描述规范每个工具注册时都需要提供名称、功能描述、参数Schema、返回结果样例、调用限制、错误码含义。有些团队甚至要求工具描述里写上“什么时候不该用这个工具”这个做法我非常推荐——它能明显降低误调用的概率。实践数据显示工具描述经过结构化重写之后调用正确率普遍提升8到15个百分点。调用鲁棒性提升更多来自工程细节。比如参数校验模型生成的目标时间和真实业务要求的格式不一致这是高频错误。解决办法是“软参数硬转换”让模型输出自然语言参数再由一个确定性的转换层负责格式整理和范围校验。再比如失败重试策略不能无脑重试同一个参数而是要把错误信息反馈给模型让它基于错误原因重新生成参数这个方式比单纯重试的成功率高非常多。还有就是工具返回结果的长度控制。很多模型一调用工具就把完整结果塞回上下文下一轮就忘掉原来的任务了。正确做法是设置“结果摘要网关”让工具返回先经过一个压缩处理将长结果转成结构化摘要只保留跟当前任务直接相关的部分。这样做既省token又减少上下文污染。2.5 安全与权限出道即红线Agent本质上是把“人操作系统的权限”交给了模型所以安全与权限管理不是可选项而是地基。2026年行业内已经形成了一套比较完整的安全机制我梳理下来有四层第一层是权限最小化。Agent能调用的工具和访问的数据必须严格限定在业务需要范围内每个Agent一个身份权限独立。某团队出过一个经典事故内部一个文档总结Agent因为权限配置过大能读取全部门所有员工的个人信息虽然最后没出泄露事件但审计时直接把他们吓得一身冷汗。管理上的原则就一句话能不给的权限一律不给。第二层是操作确认阀。高风险动作必须走人审。判断依据不是动作类型而是影响范围。比如删除数据、发送对外消息、执行金额变更、访问敏感字段这些统统都要配置人工审批环节。2026年的智能体框架普遍自带这项功能但真正把它们配置齐全的团队我估计不到三成。第三层是行为审计。Agent的每一次规划、每一次工具调用、每一次决策变更都应该有不可篡改的日志。这不是为了事后追责而是为了让“出问题时还能快速定位到具体环节”。Agent系统的排障难度本来就高没有完整审计链的话查一个问题可能要翻几百条对话记录还不一定找得到根因。第四层是防注入与恶意指令。尤其是让Agent处理外部输入的场景比如Agent自动阅读邮件并撰写回复就必须防止邮件正文里藏恶意指令诱导Agent执行危险操作。基础防护是加指令边界提示高级防护是把外部输入隔离在“不可信内容区”模型的记忆读取逻辑要显式区分系统指令、用户指令与外部内容。提示安全设计必须在架构阶段就位后面补非常痛苦。Agent系统的权限点分散在工具层、模型调用层、编排层和数据层四处一旦业务量上来之后再做权限收敛改动成本相当于重构。3. 生产环境实操从可用到可靠的关键落地项3.1 搭建生产级Agent的标准架构分层把一个跑通Demo的Agent项目升级到生产级第一步是明确架构分层。我给你一个经过多个项目验证的分层方案每一层职责单一避免互相干扰。接入层负责统一接收任务请求做格式转换、合法性校验、路由分发。对外屏蔽内部实现细节对内提供标准化的任务输入结构。编排层任务拆解、步骤规划、状态流转。这一层是Agent的大脑也是后面上多Agent时最先需要升级的地方。执行层真正调用工具、访问数据、执行模型推理把编排层的指令变成实际动作。记忆层管理短期、长期、工作记忆的存储与检索独立部署通过API供上层调用。观测层全链路日志、指标采集、运行追踪、定时巡检这是生产级系统和Demo系统最大的区别。我自己实际用下来这套分层的最大价值在于“能定位问题”。没有分层的时候Agent出错了你得翻对话记录猜原因有分层之后你能直接说“执行层第3个工具调用超时了”排障效率提高了不止一个数量级。3.2 评测体系没有评测就没有迭代很多Agent项目翻车不是模型不行而是根本不知道什么算行。2026年行业已经形成了一个共识Agent评测必须从单模型评测转型为任务级评测你要评的不是“模型回答得好不好”而是“任务完成得怎么样”。一个完整的任务级评测体系至少包含四类指标。任务完成率最基础但由于Agent会中途向人求助所以还要结合人工介入率来一起看。单次调用成功率衡量工具调用的可靠性这一项容易优化但很容易被忽略。步骤效率看完成同样任务消耗了多少步骤和多少token很多Agent能完成任务但路径极其绕成本高到你用不起。稳定性是最高权重项——同一个任务跑100次成功90次还是成功70次这决定你能不能上生产。评测集的建设尤为重要。你要从历史任务日志里抽样整理出覆盖各种边角的评测用例尤其要多放那些“模型第一次没做对、经过纠错才做对”的困难样本。不要只搞几十条Demo用例就认为评测完成生产级Agent的评测集至少要上千条而且需要定期补充新出现的失败案例来防止回归。我们团队内部有一条规矩每次上线新版本先在评测集上跑全量回归任何一项指标掉1个点都不许放行。3.3 成本优化Token开销是Agent最大的隐形杀手Agent的一次完整任务可能产生几十次甚至上百次模型调用。你可能想象不到一个常年运行的复杂Agent成本大头不是模型单次推理而是任务循环里的重复调用和上下文膨胀。省成本最有效的办法是控制上下文体积。前面提到的结果摘要网关就是一个核心手段工具返回的长内容先压缩再进上下文实测能把单次任务的token消耗降低30%到50%。其次是避免无效循环很多Agent在遇到失败时会反复用同样的方式重试徒增成本。解决方案是引入“失败模式识别”——如果错误信息相似就直接切换到备用方案或者请求人工避免低效空转。最后是模型分级调用简单任务用轻量模型复杂任务才上强推理模型。你可能觉得很基础但直到2026年仍有很多团队所有任务都走最强模型成本是合理方案的四五倍。3.4 可观测性与调试手段Agent追踪让黑盒变透明调试Agent是2026年生产实践中最大的痛点之一。传统的日志方式在Agent场景下几乎无效因为你没法靠“翻日志”来理解模型当时的决策推理链。成熟的方案是使用专门的Agent追踪工具它能记录每个节点的完整决策过程模型当时的输入输出、工具调用的参数和结果、记忆检索命中了哪些内容、步骤间状态如何流转。我强烈建议你在搭建Agent的第一天就接入这类观测工具等出问题再接就晚了因为之前的历史运行数据根本回溯不了。回放功能是一项被低估的能力。它能让你把Agent某次失败的完整过程逐帧重放看到它在每一步到底看到了什么、做了什么决策。这个体验类似于分析事故黑匣子很多难缠的随机性问题靠多跑几次回放就能发现端倪。比如某个Agent有时候会漏掉关键比对步骤后来回放发现它在处理某些数据格式时跳过了中间校验环节问题出在模型对字段类型产生了错误理解而不是随机故障。3.5 多Agent协作不是为了潮流而是解决复杂问题2026年多Agent协作依然是热点但落地成熟度明显分化。我的观察是合理的多Agent不是拿来炫技的而是在三个具体场景下才有真实价值。第一个场景是任务自然分域比如售前Agent、售中Agent、售后Agent各管一段本质上是用Agent划定责任边界。第二个场景是角色对抗与校验比如一个Agent写方案另一个Agent负责挑毛病这种“红蓝对抗”模式在内容生成和代码审查场景效果显著。第三个场景是流水线处理上游Agent产出结果后直接传递给下游Agent继续加工这种模式最容易实现且收益最稳定。但你如果只是想靠多Agent提升单个复杂任务的成功率我劝你冷静。多个模型协作意味着多个不稳定节点的串联任何一个出错都会污染全局。更要命的是Agent之间的沟通可能互相误解出现“我以为你做了你以为我做了”的情况。要上多Agent你必须先回答三个问题每个Agent的职责边界是否清晰协作的接口协议是否稳定整体流程是否能在任意节点回退重试三个问题里任何一个是否定的都建议先回到单Agent加人工协同。3.6 垂直场景调优给Agent灌入“领域方言”2026年一个明显的行业趋势是“通用Agent退潮垂直Agent涨潮”。几乎每个成功的落地案例都是在某个特定行业场景里深耕的Agent而不是试图解决所有问题的万能助手。垂直调优的关键在于领域知识注入和交互模式设计。领域知识不能只靠Prompt里写几句要靠业务知识库的检索增强也就是RAG的深度应用再加上历史操作数据的微调。你还要针对行业设计专门的交互模式比如面向财务的Agent要有凭证字号、预算科目这些概念的强校验逻辑面向客服的Agent要能处理客户的重复追问和情绪表达而不是每次都板着脸回答标准答案。我自己做垂直Agent的经验是尽早收集“领域专属失败样本”并持续迭代。用通用评测集测试垂直Agent成绩可能一直很好看但没什么意义真正能让Agent质变的是那些从生产环境里捞出来的、带着浓重行业口音的失败案例。比如某个医疗领域的录入Agent一开始遇到病历里的英文缩写就出错后来把大批真实缩写的样本加进评测和微调数据准确率才真正稳定下来。4. 常见问题与故障排查一线踩坑实录4.1 高频问题一Agent“绕圈子”任务进入死循环做一个稍微复杂点的任务Agent最容易出这个毛病——步骤来回执行工具反复调用结果却没有推进。排查思路是看循环模式和触发条件。我遇到过最典型的三种死循环工具调用返回空结果但Agent不换策略同一步骤重试次数超过设定仍不放弃以及两个工具互相覆盖对方的操作结果A写入数据B又把数据覆盖回去。解决办法有三个层次。最底层是在编排层写“任务推进检测”——每一轮循环结束都比对一次任务状态如果连续三轮没有状态变化强制触发重规划。中间层是给每个工具配置“调用次数预算”超过预算直接切换备用路径。最高一层是引入超时熔断整个Agent单次任务总执行时长超过阈值就立即停止转入人工处理通道。这套组合下来死循环问题基本能消除。4.2 高频问题二上下文污染导致任务中途跑偏Agent执行到一半突然忘了最初的目标或者开始处理跟当前任务无关的信息这是多步骤任务里的头号稳定性杀手。问题的根源大多是上下文里混入了太多干扰信息一次性塞入过大文档、工具返回了多余的参考信息、历史对话里的旧任务干扰了当前判断。我推荐的解法是“上下文瘦身三原则”。原则一每次模型调用前都从记忆区检索跟当前步骤最相关的信息而不是把整段历史全塞进去原则二工具返回的结果必须经过摘要网关压缩无关字段直接丢弃原则三在系统指令里写明“当前任务目标”和“已完成步骤”摘要并让它每一步都先确认这两个状态再行动。保持这三条纪律之后跑偏率能降低一大截。4.3 高频问题三输出格式不稳定模型生成的JSON偶尔多一个字段、少一个引号这在Agent调用链里会造成连锁崩溃。越是复杂的Agent越容易在格式上翻车因为工具调用解析一旦失败后面的步骤全得重来。不推荐的做法是反复在Prompt里强调“必须输出严格的JSON格式”实测效果不稳定。更好的方式是用“结构化输出模式”有些模型原生支持强制按Schema输出即使不支持也要在模型输出之后加一个“解析容错层”用程序做容错解析格式错误时自动修复常见问题多了的逗号、漏掉的括号修复不了再让模型基于报错信息重新生成。另外养一个好习惯输出的结果先落盘再做下一步使用。这样就算下一步解析失败你也不会把原始正确数据搞丢。4.4 高频问题四Agent在关键环节产生幻觉幻觉问题到现在也没法根治但能防住。生产里最实用的策略是“关键事实校验”——凡是Agent生成的内容涉及具体数字、日期、人名、合同条款时强制让它引用来源依据程序侧再对这些关键字段做交叉验证。举个例子某Agent负责生成采购订单复盘结果经常把单价和总价搞错。后来加了一道程序校验先从原始采购记录里抽取出单价、数量、税率再把Agent输出里的对应字段逐一比对不一致就打回重新生成。就这么一道简单防线报销审核的一次通过率从76%提到了94%。应对幻觉思路不是让模型变得更诚实而是建立一条独立于模型的事实校验链路。4.5 高频问题五性能瓶颈与并发控制Agent任务往往比常规API调用慢得多一次任务几十次模型调用串行下来延迟动辄几分钟。如果你要支撑多个用户并发使用后端资源调度必须重新设计。我的建议是第一原则“能并行就并行”。多个独立的子步骤同时执行比如同时查询多个数据源、同时调用多个分析工具能将整链延迟压缩到串行模式的1/3左右。第二原则是“控制并发上限”。Agent任务对模型接口的调用频率很高一定要在接入层做令牌桶限流防止单个任务把上游模型的配额全部打满。第三原则是把Agent任务改成异步化设计提交任务后立刻返回任务ID后面通过轮询或回调拿结果。同步阻塞式等待在Agent场景下体验很差而且容易造成系统资源被长时间占用。4.6 排查工具与调试流程最后说一下排错流程。我建议你建立一套标准化的“三层排障法”。第一层查链路用Agent追踪工具检查任务流转到哪一步断了这一层能解决六成问题。第二层查决策回放模型决策过程看在出问题的那一步模型当时看到的是什么输入、为什么做出错误决策这一层能再解决三成问题。第三层查环境检查外部依赖是不是发生了变化——数据库表结构改了、第三方接口限流了、某个文件格式换了这类环境问题往往是最难发现的隐藏雷。提示建立一个团队共享的“Agent事故复盘库”每次排查完一个问题就把现象、根因、解决手段记录进去。半年之后你就有了一本属于自己系统的实战排查手册它的价值比任何外部教程都高。5. 个人经验与2027年前瞻往后这一年该怎么走踩过很多坑之后我现在做Agent项目有一套自己的判断标准分享出来供你参考。第一先想清楚“这个任务是否真的需要Agent”。如果规则确定、流程固定传统程序十毫秒就完成了没必要让模型从零开始绞尽脑汁。Agent的用武之地是那些“输入不结构化、规则有弹性、需要理解意图”的任务这个边界感想清楚了才能把资源花在刀刃上。第二做Agent要像带新人一样设计协同样式。给它明确的目标、给它提供必要工具、关键节点帮它把关失败了复盘改进做得好了让它接手更多权限。第三别迷恋“全自主”2026年最稳定可靠的模式依然是“Agent做90%的活人做10%的关键决策”这种混合模式运营成本低、而且业务方接受度反而高。展望2027年我在一线看到这些趋势大概率会加速。模型侧的进展会持续拉升Agent的能力上限但工程侧“如何把上限变成稳定的下限”这盘棋才开始进入深水区。未来的Agent系统会在三个方向出现明显分化一个是“极简化”工具链更收敛、编排更直接企业只管自己能掌控的小而美场景另一个是“平台化”多Agent编排、治理、审计能力逐渐沉淀为标准平台能力还有一个是“具身化”Agent开始从数字世界走进物理世界的交互场景比如控制硬件设备、协调仓储物流这个方向2026年已经在试点了。最后分享一个实在的建议2027年想持续跟上这波浪潮不要只追模型版本的更新把更多时间花在你所在行业的业务链路理解上花在数据资产的整理上花在评测体系的打磨上。模型会越来越强但能把模型能力变成稳定业务价值的团队永远是那些把工程细节抠到极致、把业务问题琢磨透的人。我见过太多团队换了更强的模型后Agent性能反而下降原因正是评测和防护机制没跟上——能力大了闯祸的半径也大了。这一点希望读到这里的同行都能少走弯路。