1. The Devil Is in the Interface: Evaluating How Tool Architecture Shapes Coding Agent Behavior

推荐理由: 很多 agent harness 的讨论都在问“应该再加什么 tool”,这篇论文把问题推进了一层:即使底层能力几乎相同,tool architecture——能力以什么抽象层级、什么接口形态暴露给模型——本身就会显著改变 agent 行为。这对设计 coding agent、MCP/tool schema 和 agent runtime 很实用,因为优化点不一定是增加能力,也可能只是重新设计接口。

核心要点:

  • 作者在 repository-level issue fixing 上比较 6 种工具架构、3 个 actor model,总计运行 11,700 条 trajectories,并尽量保持底层 capability 相同,只改变接口组织方式。整体 task resolve rate 相近,但 consistency、repository exploration 和 efficiency 明显不同,说明 harness 的“非功能属性”可以由接口设计单独塑造。
  • 把 grep、bounded file view、targeted replacement 等常用操作封装成结构化 Atomic tools,可把重复运行的一致性最高提升到 BashOnly 的 4.7×;自然语言搜索接口则让 agent 访问高相关文件的 recall 提升超过 11%,代价是 precision 下降和更多噪声。也就是说,tool abstraction 会直接改变 agent 的搜索策略,而不只是调用便利性。
  • Python CodeAct 风格接口在相近成功率下减少 41.6% interaction steps56.3% token usage,因为模型能把多个动作组合进一个可执行块。相反,简单的 scratchpad / hypothesis-tracking 工具几乎没有改变底层 reasoning behavior。工程启示是:优先优化 action interface 和 compound execution,再考虑继续堆 cognitive scaffolding。

2. Agentic Configuration Management (ACM): A Reference Configuration Model for Governed Agentic Systems

推荐理由: 当 agent 系统从一个 prompt + model 变成由 agents、prompts、tools、models、skills、policies 和 workflows 共同组成的动态系统后,传统 AgentOps 只做 observability 已经不够。这篇尝试把经典 Software Configuration Management 的思想移植到 agent 系统:把整个 agent system 看作可版本化、可基线化、可追踪依赖、可重放的配置图。 这是 agent 进入生产环境后很容易被低估的一层基础设施。

核心要点:

  • ACM 将 agent、prompt、tool、model、skill、workflow 等抽象为独立版本化的 Agentic Configuration Items,并用 immutable revisions、release baselines 和 typed dependencies 组成 canonical Configuration Graph;runtime execution 与 configuration 明确分离,运行时实体仍保留到配置 revision 的 provenance。
  • 不同框架通过 semantic projection 映射到同一治理模型。论文给出 LangGraph、CrewAI 和 OpenAI Agents SDK 三套 adapter:无论原生表示是 workflow graph、Crew/Flow,还是 agent handoff,最终都规范化为同一种 Configuration Graph,之后的 validation、impact propagation 和 governance 不再依赖具体 framework。
  • 参考实现用 27 个 governance scenarios + 9 个 impact-propagation cases 做验证;在测试范围内,三种框架都产生 governance-equivalent representation 和可复现结果。更重要的系统启示是:未来的 AgentOps 可能需要像 Git + package graph + policy engine 的结合体——不仅记录“agent 做了什么”,还要回答 它当时运行的是哪一版 prompt/model/tool/workflow,某个配置变化会影响哪些下游执行,以及能否确定性重建。