1. The context tax: why your coding agent reads the same 600 lines 400 times

推荐理由： 这篇把 coding agent 的 context engineering 问题量化到了真实 PR 轨迹：大量成本并不是来自“推理本身”，而是 Agent 用 grep + read 做代码导航后，把大段无关文件内容带进后续几百轮 context。它提供了一个很工程化的替代方向：让 Agent 查询语义依赖图，而不是不断扫描文件。

核心要点：

  • Context 的真实成本取决于“进入得多早 × 存活多少轮”，不只是一次读了多少 token。 Sonar 给出的一个约 800 行 PR 案例经历 512 次模型 round-trip，峰值 context 约 458.7k tokens，总计约 156M context tokens / $41；其中 152.8M 是重复 cache-read。
  • 一个典型 over-read 是为了理解约 67 行 helper，却读取了整个 618 行文件。多出来约 5,770 tokens 在剩余约 470 轮里反复被带入，累计约 2.7M cache-read tokens。18 个相似 PR 平均约 234M context tokens、约 $65/PR，并经常逼近 1M context window。
  • Sonar 的 SemSitter 用 Unified Dependency Graph 表示 calls、references、returns、type、contains 等关系，让 Agent 直接查询“这个调用绑定到哪个定义、返回什么、谁调用它”，只把相关节点放进 context。对 coding-agent harness 的启示是：代码导航本身应该成为结构化能力，而不是让 LLM 在文本文件系统上模拟 IDE。

注：这些成本和 token 数来自 Sonar 自己的内部代码库与产品实践，不能直接外推到所有 Agent；更有价值的是它揭示了“context lifetime”这个容易被忽略的成本模型。

2. Manage agents, tools and skills at scale with AWS Agent Registry

推荐理由： 当组织里不再只有几个 Agent，而是几百个 agents、MCP servers、tools 和 skills 时，真正的问题会从“怎么造 Agent”变成“有什么、谁维护、哪一个可信、哪个版本能用”。AWS Agent Registry 把这类 agent sprawl 当成类似 package registry / service catalog 的平台工程问题处理。

核心要点：

  • Registry 把资源分成 MCP、Agent、Skill、Custom 四类，并记录 owner、版本、lifecycle、security/compliance metadata。目标不是单纯存放 metadata，而是形成组织级的 authoritative inventory，减少重复造轮子和 shadow agents。
  • 架构明确拆成 Governance Plane + Discovery Plane：前者保存完整资源和审批/合规状态；后者只向开发者和 Agent 暴露通过组织门槛的 curated catalog。也就是说，Agent 能“搜到什么”本身就是治理策略的一部分。
  • Discovery 同时支持 semantic + lexical search，并把 Registry 自身暴露成 MCP server，因此 Claude Code、Kiro 等 Agent 可以在执行过程中按意图动态发现工具和 skill，而不是把上百个 tool definition 全塞进 context。对 software factory 的启示是：skill/tool routing、权限、provenance 和 lifecycle 应该成为共享基础设施，而不是散落在每个 Agent 的 prompt/config 里。

注：文章包含 AWS 产品发布与客户案例，因此部分收益描述来自厂商自身；更值得关注的是“治理平面与发现平面分离”的架构模式。