1. The Economics of Agent Optimization: Context engineering for enterprise AI agents

推荐理由： 这篇值得看，不是因为它重新定义了 context engineering，而是因为它把 context 拆成了可以分别治理和优化的四类系统资产：knowledge、tools、skills、memory。更重要的是，它把目标从“尽量塞更多上下文”改成了 让每一轮只看到完成当前任务真正需要的东西，并用 retrieval、tool search、skill loading 和 memory lifecycle 把这种选择做成持续优化的 runtime 能力。对长期运行的 Agent 来说，这比单纯做 prompt compression 更接近真正的 context control plane。

核心要点：

  • Context 成本是多轮 Agent 的复利成本。 每一轮都会重复发送 instructions、tools、retrieved docs 和 history，因此无关内容不仅占一次 token，而是会被后续 turn 反复计费。Microsoft 的结论很明确：context engineering 的核心不是“压缩 prompt”，而是持续决定每一轮该让模型知道什么、能调用什么、该遵循什么 procedure、该记住什么。
  • Tool / Skill 应该按需发现，而不是常驻 context。 Foundry Toolbox 让 Agent 先通过 tool search 找能力，只暴露少量描述，再按需加载完整 tool/skill。Microsoft 的内部 benchmark 显示，在大型 tool library 上，tool search 可把平均 input-token consumption 降低约 97%；Foundry IQ 的内部评测则报告 evidence recall 最高提升 54%、retrieval token cost 降低 34%。这些数字是厂商内部测试，但它们很好地说明了一个方向：capability discovery 应成为 harness primitive。
  • Memory 与 Skill 是两类不同的长期知识。 Skill 保存组织批准的 procedure；procedural memory 则从具体任务执行中积累“这个 Agent 怎么做得更好”。前者可版本化、集中治理，后者随运行增长。Microsoft 报告 procedural memory 在 STATE-Bench 和 Tau-Bench 上约带来 5% 提升。更关键的设计点是：长期 Agent 不应该把所有历史都拖进对话，而应该把不同类型的长期信息放进不同生命周期和权限边界中。

核心启示：context engineering 正在从“写 prompt”变成一个独立的系统层：它负责 knowledge retrieval、capability discovery、procedural guidance 和 memory lifecycle，并直接决定 Agent 的成本、准确率与可治理性。

2. How Intuit built an agentic disaster recovery assistant with Amazon Bedrock

推荐理由： 这是一个很少见的、真正进入生产高风险操作面的 Agent 实践。Intuit 原有 EWOK 已经能把支持 workload 的 disaster-recovery failover 从数小时缩短到约 20 分钟，但 workflow 选择、readiness 判断和异常处理仍依赖 on-call 的隐性知识。EWOK Agent 的价值不是替代这些确定性系统，而是在上面增加一层受约束的 reasoning：模型决定 what，传统系统执行 how。 这比“让 Agent 直接拿 shell / cloud 权限”成熟得多。

核心要点：

  • 把 Agent 放在既有 deterministic control plane 之上。 EWOK Agent 分成 consumer、agent、skill、execution 四层：用户从 portal/IDE 发自然语言请求，模型选择 skill，skill executor 调用 EWOK API，真正的 asset resolution、policy gate、change record 和 failover 都由已有测试过的代码完成。模型不会直接执行生产变更，也不会替代灾备系统本身。
  • Skill 是 typed capability，不是一段自由文本 prompt。 每个 skill 由 versioned YAML schema + prompt body 定义，再编译成 Bedrock Converse API 的 tool specification。模型只负责选择哪个 skill 以及结构化参数；executor 才持有 request-scoped identity 并调用实际 API。这个边界把 reasoning、authorization 和 execution 分开，也让模型可以替换而不用重写底层 workflow。
  • 生产 Agent 的安全来自外部约束，而不是模型自律。 模型不持有 AWS credentials，也没有直连 EWOK 的 network path；状态变更返回 typed JSON，生产 failover 和 freeze-window override 等关键动作需要显式人工批准；所有 invocation、tool call 和 change record 都进入 audit trail，并配合 least-privilege IAM、rate limit 和 guardrails。Intuit 表示该 Agent 已被团队用于 failover 约 8 个月。

核心启示：对于能够改变真实生产状态的 Agent，最稳妥的架构不是扩大模型权限，而是让模型停留在 interpretation / selection / coordination 层，把 authorization、execution、audit 和 verification 留在确定性的控制面中。