1. Engineering the Frontier Firm: Sharing our AI-native approach to software development

推荐理由： 这是 Microsoft Digital 对内部 AI-native 软件工程转型的最新总结。它最有价值的地方不是再强调“AI 能写更多代码”，而是明确指出：个人开发效率提升并不会自动转化成团队吞吐，真正的瓶颈是传统 SDLC 中反复的人际 handoff 和业务意图丢失。Microsoft 因此把 spec-driven development（SDD）作为新的控制面，让 specification 成为 PM、架构师、开发、测试和 coding agent 共同消费的 living artifact。

核心要点：

  • 从 code-centric 转向 intent-centric。 Microsoft 的实践把 specification 从一次性的规划文档升级为项目的 source of truth，持续保存 business intent、acceptance criteria、约束和 edge cases。代码、测试和 Agent 执行都围绕 spec 推进，而不是让 prompt 或最终代码反过来定义需求。
  • AI-native SDLC 的关键是把判断前移。 团队把更多 critical thinking、跨角色协作和 ambiguity resolution 放到 requirements/spec 阶段；架构师还会先建立包含架构原则、安全、治理和开发约束的“constitution”。这样 coding agent 获得更快执行速度时，不会把需求模糊放大成更多返工。
  • 角色也随控制面变化。 PM 从 backlog owner 变成 spec owner，architect 维护 guardrails，AI 负责生成、测试和验证的执行工作，人仍负责方向、判断和最终验收。Microsoft 的经验是：AI-native engineering 的核心指标不是生成了多少代码，而是 业务意图在从需求到实现的整个链条中保存得有多完整。

核心启示：当代码生成越来越便宜，specification 不只是文档，而会逐渐变成 software factory 的可执行控制面。

2. Building an agent harness that survives production

推荐理由： 这篇很适合作为 production agent harness 的架构清单。Oracle 把 harness 与 framework 明确区分：framework 提供 graph、message、tool adapter 等构造材料，而 harness 是真正绑定生产身份、凭证、权限、状态、执行限制、恢复机制和 acceptance test 的运行时边界。它回答的不是“Agent 会不会做”，而是“Agent 被允许做什么，以及怎么证明它真的做完了”。

核心要点：

  • 模型提议，harness 授权，环境执行，verifier 判定结果。 Oracle 将责任边界拆得很清楚：身份和凭证永远不应该由模型自己声明；完成状态也不能相信模型的自然语言总结，而要从真实系统读回 evidence。更强的模型可以减少补偿性 scaffolding，但不会消除 permission 和 independent verification。
  • 状态、memory 和 checkpoint 不是同一件事。 Prompt summary 或 compacted context 只能帮助下一轮推理，不能替代 durable runtime state。长时间 Agent 如果需要跨重启继续工作，应把 run state、tool evidence、limits 和恢复位置持久化，而不是假设一段摘要就是 checkpoint。
  • 生产 harness 应当被像基础设施一样测试。 Oracle 建议逐项检查 harness 的 identity、tool boundary、limits、continuity、verification 等机制，并问三个问题：有没有明确 owner、有没有真正 enforcement mechanism、有没有 failing test。只有 prompt guidance 而没有外部 enforcement 的安全或完成条件，都属于需要优先治理的生产风险。

核心启示：Agent framework 决定“怎么构建 Agent”，production harness 决定“Agent 在真实世界里拥有什么权力，以及什么证据才能让一次执行算完成”。