当天最强的信号是，在真实约束下对智能体工作的实际测量。MAC 和 TeleSWEBench 显示，智能体在设计另一个智能体和修复领域代码方面的自主性都有限。其余论文集中在让智能体输入、工具和运行时证据可审计。
大语言模型（LLM）智能体评估正越来越接近完整工程工作。Meta-Agent Challenge 给一个编码智能体提供沙箱、API、开发集和隐藏验证器，然后要求它构建另一个智能体。可见的最佳结果在一些领域大致达到人类基线，但不同模型和任务之间表现差异很大，在科学问答上差距明显。
TeleSWEBench 增加了一个面向领域的压力测试。它从真实的 srsRAN 5G 提交记录中构建 734 个任务，并要求先定位文件，再做功能评分。最强的自动化软件工程工具最高能产出 25% 的可交付修改，而当提示给出的编辑细节减少时，定位率会明显下降。这把瓶颈说得很清楚：仓库规模、协议密集的代码仍然能难住很多当前智能体。
几篇论文把智能体成功看成可用证据的问题。过程分类法用六个维度评估六个高热度的 AI 开发支持工具：规格、上下文、角色、执行、验证和可移植性。它最清楚的发现是覆盖不均：更丰富的制品提高了可追溯性，但跨智能体的可移植性更难。
Context-as-a-Service 给出更具体的机制。它让智能体在文档审查时查询已索引的源文件、测试、示例和文档。在两个生产 SDK 案例研究中，它把保留的问题数量从 5 提高到 13，并缩短了墙钟时间和输入 token。Self-reflective APIs 在 API 边界上提出了类似观点：对于所测试的 Anthropic 模型，结构化修复建议比更长的文字错误说明更能帮助智能体从验证失败中恢复。
智能体可靠性取决于模型在规划时推不出来的事实。Model Context Protocol（MCP）研究测量了来自 2,214 个服务器的 19,200 对工具的描述与代码不一致。DCIChecker 报告 9.93% 的工具对存在不一致，包括省略行为、夸大能力和隐藏副作用。这些错误会误导工具选择，并留下安全盲点。
Ekka 处理 LLM 推理中的另一种隐藏故障模式。它把目标服务引擎和参考实现放在中间模型状态上对比，然后给最先出现输出分歧的组件排序。在真实的 vLLM 和 SGLang 静默错误上，它报告的诊断准确率是 pass@1 80%、pass@5 88%。这个结果很重要，因为只看输出的检查常常会漏掉出错层：模型代码、内核后端、数值精度或服务逻辑。
这些面向运行的论文关注的是智能体在重复工作中能记住什么、能查询什么。UModel 把可观测性数据变成服务、Pod、主机、指标、日志、链路、事件、runbook 和工具的关联对象。在 AIOps 2025 Challenge 数据集上，论文报告它比朴素智能体方法的根因定位提升 8%，并描述了超过一年的阿里云部署。
Stigmergy 提案把记忆用于工具选择。它把工具、MCP 工具和技能作为节点存进本地图，转移边上带有随时间衰减的成功与失败证据。证据还很早：文章给出了平台 token 成本动机和一个已实现的设计，但核心的受控 token 降低测试仍未完成。它真正有用的部分，是明确提出智能体应把结果历史带到后续能力选择中。