1. JetBrains Air: Building a System of Products for Agentic Software Development

推荐理由： 这篇不是单纯发布一个新的 coding agent，而是在定义 JetBrains 对下一代 software factory 的系统边界：开发者需要一个执行与验证环境，团队需要协调 autonomous agents，组织需要独立的 policy、audit、cost 和 accountability 层。更值得注意的是，JetBrains 明确把 multi-vendor 当成前提，并尝试用 ACP 把不同 Agent 的完整 harness 接进同一套上下文与治理系统。

核心要点：

  • Agentic development 正在从 IDE 内功能扩展成组织级系统。 JetBrains 把 Air 拆成 Air in JetBrains IDEs、Air Teams 和 Air Governance：前者负责 directing / orchestrating / verifying agent work，Teams 负责把 individual agent sessions 变成可自动化的软件交付 workflow，Governance 则负责 policy、visibility、auditability、cost management 和 accountability。它反映出 coding agent 的产品边界正在从“写代码”扩展到整个软件生产控制面。
  • 未来默认是 multi-vendor，而不是统一到一个 Agent。 JetBrains 认为不同模型和 Agent 会长期并存，因此用 Agent Client Protocol（ACP）标准化 IDE 与 Agent 完整 harness 的连接，包括 planning、tools、model routing 和 observability。真正需要统一的不是模型，而是 Agent 之上的 shared context、policy、cost view 和 execution record。
  • 瓶颈正从生成代码转向验证、理解和责任归属。 Agent 可以让代码更便宜，但“几乎正确”的改动会让 review 与 verification 更贵。JetBrains 因此强调 deterministic code intelligence：让 Agent 直接访问语言、结构与代码关系等已有事实，而不是反复用 token 重新发现它们；人和组织仍负责最终验证与接受变更。

核心启示：团队 Harness 平台不应只是统一安装 Skills 或 Agent。更完整的抽象是 execution environment + shared context + deterministic code intelligence + workflow orchestration + governance + cost/traceability，并且模型与 Agent 应作为可替换执行后端。

2. The Genie One MCP is now Generally Available

推荐理由： 这篇展示了一种比“给每个 Agent 单独做 RAG”更接近组织级 context engineering 的架构：把统一业务语义、数据访问、权限策略和审计做成一个可被所有 Agent 调用的 MCP 服务。重点不是 MCP 协议本身，而是 context 应该成为集中治理、持续更新、跨 Agent 复用的基础设施。

核心要点：

  • 共享 Context Layer 可以消除 Agent 之间的语义分叉。 Genie One MCP 通过 Genie Ontology 给不同 Agent 暴露同一套业务定义，并同时访问 structured tables 与 unstructured documents。这样 Claude、ChatGPT、Cursor 或内部 Agent 不需要各自维护一份容易过期的业务 context，而是通过同一个入口获得一致语义。
  • Context 服务同时也是治理边界。 Genie One MCP 运行在 Unity Gateway 的 managed MCP Service 中，统一承载 fine-grained policy 和 audit logging。也就是说，企业 context 不只是“可以检索的知识”，还需要规定谁可以读什么、调用了什么以及结果来自哪里，这使 context engineering 与 governance 实际上成为同一个平台问题。
  • 业务 Context 可以直接进入 coding-agent workflow。 Databricks 给出的例子是：coding agent 修改产品日志或相关代码时，可通过 MCP 获取当前产品定义、指标与查询逻辑，避免代码实现与组织现行的业务语义发生漂移。复杂请求还可以由统一入口进一步路由到 domain-specific Genie Agents，而不要求上层 Agent 自己理解所有数据系统。

核心启示：组织级 context engineering 的目标不应是“让每个 Agent 都拥有更多知识”，而是建立一个 authoritative context service：统一语义、按需检索、动态更新、权限控制、来源可追踪，并通过标准接口被不同 Agent 复用。