【Agent Engineering Radar】2026-06-16 Agent 工程技术雷达

Posted on

今天的信号很明确：agent 技术栈的竞争正在从“哪个框架更会跑 demo”，转向“哪个框架更容易被实现、验证、观测和约束”。近期几篇评测型论文和工具文档都指向同一个结论：不要先押注单一框架，先把评测、工具边界、trace 和安全门槛做成自己的吸收系统。

Today’s Signal

ADK Arena 把 51 个 Python Agent Development Kit 放到同一套自动化流程里比较：让同一个 coding agent 学文档、写 agent、修复到测试通过，再跑 SWE-bench、tau2-bench、Terminal-Bench 和 MCP-Atlas 适配器。结果很适合做技术雷达的判断依据：框架生成成功率只有 57%，生成成本相差 5.6 倍，单一 benchmark 上的最佳框架可以做到很强，但中位框架只有 32% 左右的任务解决率。来源：arXiv:2606.05548

这说明“社区热度”不能直接等同于“可进入主技术栈”。一个 agent 框架至少要过三关：开发者能否快速写对、工具/状态是否可测试、失败时是否可诊断。

Adopt

评测先行，而不是框架先行

把每个新框架都放进同一个最小评测夹具里：工具调用、文件读写、长任务恢复、人类确认、trace 输出、失败重试。ADK Arena 的方法给了一个实用启发：固定任务和验证标准，再比较框架差异，而不是只看文档示例。

下一步：维护一个本地 agent-stack-smoke，每个候选框架都必须跑同一组任务，输出成功率、步数、token 成本和失败原因。

Agent 可观测性作为默认能力

OpenInference 已经把 LLM 调用、检索、外部工具调用等上下文纳入 tracing 规范，并提供 OpenAI Agents SDK、MCP、LangChain、LlamaIndex、CrewAI、AutoGen AgentChat 等 instrumentation。来源：OpenInference

OpenTelemetry 也已经把 Generative AI、Agent spans、MCP、OpenAI 等语义约定列入文档目录，说明 agent trace 正在从厂商插件变成通用工程接口。来源：OpenTelemetry GenAI semantic conventions

下一步：新 agent demo 默认记录 model -> tool -> observation -> decision -> artifact trace，不接受只有最终答案的 demo。

Trial

对话式 coding agent 评测

Dialogue SWE-Bench 关注交互式 coding agent，而不是完全自动解题。它引入用户模拟器和对话质量评估，并指出 coding 能力和 dialogue 能力不是同一个维度。来源：arXiv:2606.13995

这对个人工作流很关键：很多真实开发任务不是“一次性 issue -> patch”，而是 agent 需要澄清范围、解释风险、接收用户修正、在新信息下调整计划。

下一步：把本地评测分成两类：autonomous task 和 dialogue task。前者看完成率，后者还要看澄清质量、是否过早动手、是否保留用户约束。

MCP 作为连接层，但不直接等于可信执行层

MCP 官方定义是连接 AI 应用和外部系统的开放标准，可接数据源、工具和 workflow。来源：MCP 官方文档

这适合进入 Trial，而不是无条件 Adopt。原因是 MCP 解决的是接入标准化，不自动解决身份传播、工具预算、结构化错误、安全审计和权限隔离。

下一步：只把 MCP server 放进最小权限 sandbox；每个工具必须有输入 schema、输出 schema、超时、审计日志和禁用开关。

Watch

Skills 的真实增益比直觉更窄

SWE-Skills-Bench 测了 49 个公开 SWE skills，结果显示 39 个没有带来 pass-rate 改善，平均增益只有 +1.2%；只有少数特化 skill 有明显收益，且版本不匹配的指导会伤害结果。来源：arXiv:2603.15401

这不是说 skills 没用，而是说明 skill 必须足够贴近任务、版本和项目上下文。泛化的“最佳实践包”很容易变成 token 负担。

下一步：skill 进入个人栈之前要有 paired eval：同一任务有 skill / 无 skill 各跑一组，比较成功率、token、错误类型。

Terminal 任务的 benchmark 正在变硬

Terminal-Bench 2.0 提供 89 个真实终端环境任务，带环境、人工解法和测试；官方页面也展示了系统管理、安全、数据处理、模型训练等任务样例。来源：Terminal-Bench

TerminalWorld 则从真实终端记录中构造任务，Verified 子集上当前系统最高 pass rate 约 62.5%，并指出它和 expert-curated benchmark 的相关性很弱。来源：arXiv:2605.22535

下一步：不要只用 coding benchmark 判断 agent 能力。终端任务要单独看：命令规划、环境感知、文件副作用控制和恢复能力。

Hold / Risks

不要把“框架支持 MCP / tracing / memory”当成生产成熟度

今天的公开材料共同说明一个风险：很多能力已经有接口，但没有形成可靠的工程闭环。MCP 有连接层，OpenInference 有 trace 层，ADK 有框架层，benchmark 有评测层；真正可用的技术栈需要把这几层接起来。

暂缓动作：不要因为一个框架新增某个集成就迁移主栈。先让它跑过本地 smoke、trace、权限和失败恢复检查。

不要盲目积累 skills

Skills 更像精密工具，不是知识库越大越好。版本错位、抽象层级过高、和项目上下文冲突，都会让 agent 更慢或更错。

暂缓动作：只保留能通过项目级验收的 skill；过期 skill 要归档，而不是长期塞进默认上下文。

Practical Stack Adjustments

本周可以先做四件小事：

  1. 建一个最小 agent smoke suite，覆盖工具调用、文件修改、测试、恢复和 trace。
  2. 给每次 agent 实验记录四个指标：成功率、成本、步数、失败类型。
  3. MCP server 默认放入 Trial 清单，必须通过权限和日志检查后再进入常用工具集。
  4. Skills 采用 paired eval，不再凭主观体验直接加入默认上下文。

今天的结论：Agent Engineering 的技术视野要保持开放，但吸收机制要收紧。框架、协议、skills、benchmark 都可以快速跟进；真正进入主技术栈的，只应该是能被验证、能被观测、能被回滚的部分。