本文对比了 Pi Durable 与 OpenCode 两种编程 Harness 架构。传统 Harness（如 Claude Code、Codex、OpenCode）采用会话式架构：运行中的 Agent Loop 驱动模型调用与工具执行。Pi Durable 则将模型生成、工具调用、压缩及应用工作全部建模为持久化任务，由调度器基于存储状态决定执行，实现崩溃恢复与进程解耦。文章从五个维度展开：Agent Loop 序列化到存储、工作可调度、应用状态与对话的原子绑定、压缩移出关键路径、以任务图形式实现委托协作，展示了持久化任务架构带来的全新 Harness 能力。
文章回顾了 MCP 协议 18 个月来的架构演进。MCP 最初由 Anthropic 于 2024 年 11 月推出，作为向模型暴露外部能力的工具层。OpenAI 虽然较晚采用，但推动了大量创新：先是 Apps SDK 让集成方提供交互式界面，随后社区提出官方 MCP Apps 扩展实现跨主机可移植。2026 年 DevDay 上，OpenAI 发布 Plugin Extensions，让 MCP 应用深度集成到 ChatGPT 的侧边栏、对话面板等界面，并新增 MCP Events，使外部系统能通过 webhook 主动触发 ChatGPT 中的工作。MCP 正从能力层演变为完整的应用架构标准。
文章探讨了决策模型 Jev 在 DevOps 领域的早期应用，提出“JevOps”概念。DevOps 充满大量小型语义决策（如日志是否值得调查、告警是否严重、修复是否有效等），传统依赖确定性规则、分类器或 LLM。Jev 以低成本、低延迟的方式将这些语义决策直接嵌入运维系统。文章列举了多个案例：Cribl 探索遥测管道中的语义决策、Jev Logs 实现日志分流、Jevernetes 应用于 Kubernetes 日志、Datadog 将 Jev 用于生产环境 Agent 评估、SREGym 在 SRE Agent 旁构建第二评估循环、以及 Jev 对高风险动作的语义门控审查，展示了决策模型在各运维环节的广阔前景。
文章探讨编码智能体架构的演进：单会话聊天窗口已无法承载日益庞大的智能体任务。作者总结了六大新兴架构模式，重点阐述三种：主智能体正在转变为编排者，通过委派子智能体完成工作（如 OpenAI Agents API、Cursor Projects、GitHub Copilot、Gemini CLI）；子智能体作为临时隔离的工作单元，可在独立沙盒或 worktree 中运行，随需启停；工作状态正从智能体会话中迁移到外部系统（Git、知识库、共享记忆等），使工作可以超越单个会话的生命周期。文章认为更大系统而非单个会话正在决定智能体智能的运用方式。
文章介绍 TypeSafe 发布的 Jev 模型，一种用于快速语义决策而非生成或长推理的 System One 模型，延迟低至 70ms 且成本低廉。作者认为这类模型可将小型语义智能分散嵌入应用的各个决策点，而非集中于 Agent 循环中，从而推动微推理时代的到来。这将使代码库中包含更多非确定性判断，同时应用层更明确地掌控编排控制流，推理模型则退居处理模糊和复杂案例的升级路径。文章还探讨了围绕微推理所需的基础设施（批处理、缓存、模型路由），并以自动驾驶和 Waymo 的 ML-primary 架构类比这种通用语义模型进入控制循环的新范式。
文章提出上下文基础设施正出现一种新模式：尽可能保存原始历史数据（对话、工具调用、事件、Agent 工作记录），之后再按需构建摘要、知识图谱、嵌入等派生视图。这一架构借鉴了数据湖屋（Lakehouse）的经验，如 Databricks 的青铜/白银/黄金分层架构。作者对比了写入时即做压缩决策的内存系统（如 CrewAI），指出其风险在于丢失未来可能重要的信息；并介绍了 CortexDB、Statewave、Supermemory、Zep 等产品的实践：以不可变事件为事实来源，将记忆作为可重建的视图。文章最后提醒需防范上下文沼泽，建议写侧优化保存、读侧优化实用性。
文章探讨了MCP基础设施的演进趋势：MCP服务器正逐渐成为实现细节，其发布的接口与Agent实际消费的接口分离。中间层基础设施可以重塑工具发现、选择、认证和执行。多个服务器可聚合为单一端点，工具与实现服务器解耦，发现流程分阶段进行，工具定义作为检索上下文而非全部加载，甚至以编程接口形式呈现。这些变化使MCP接口更难测试和控制，开发者需适应新的架构模式。
Google 一年前推出的 A2A 协议已发展到 1.0 版本，获得 150 多个组织支持并进入 Agentic AI 基金会。但同期 MCP 能力日益强大、Agent 运行时的编排能力提升、长时任务转向持久化工作流、共享状态协调等方式，都在减少 agent 之间需要独立寻址通信的场景。文章分析了四种架构趋势：agent 藏身于 MCP 能力之后、子代理成为运行时内部原语、单一协调代理面向多个 agent、软件工厂按工作任务组织 agent、以及传统工作流编排器从顶层协调 agent，认为显式 agent-to-agent 协议的需求可能并不常见。
文章分析了 OpenAI Agents API、Anthropic Claude Managed Agents、AWS AgentCore Harness 和 Microsoft Foundry Agent Service 等托管式 Agent 基础设施的共同架构趋势。前沿实验室主张模型与 harness（代理执行框架）协同构建，以获得更好的效果。文中总结了四个关键模式：将 Agent 声明式资源化、为 Agent 引入版本化发布工程（含 A/B 测试）、在会话内动态选择模型实现解耦、以及将工具移出 Agent 之外的共享基础设施（MCP、Toolbox、Gateway）。作者提出开发者需要思考两个问题：应保留多少 Agent 循环的控制权，以及 harness 是否必须来自模型提供商。
文章探讨将 LLM-as-Judge 从离线评估工具迁移到 Agent 运行时架构中的趋势。传统确定性软件可通过类型检查、断言等方式验证结果，而 AI 应用输出往往需要判断性评估，LLM judge 能让应用自我完成这些判断。作者介绍了几种常见模式：使用另一个模型（包括专用小型评估模型以降低成本）、将大而模糊的判断拆解为多个小判断并用 DAG 结构组合、用成对比较代替打分以规避位置偏差、在 Agent 工作过程的关键节点（如检索、方案选择）设置检查点而非仅评估最终答案，以及使用多评委投票、辩论等机制提升可靠性。
文章探讨了 Snowflake、Databricks、ClickHouse、BigQuery、MotherDuck 等数据仓库平台在 AI 时代的架构演进，总结了七大架构经验：推理正在成为数据库算子；数据转换可通过 LLM 推断并物化新事实；语义层正成为 Agent 的基础设施；Agent 的部署位置是重要的架构决策；数据仓库正成为 Agent 工作的执行环境；Agent 是一种新的数据库工作负载，其迭代、突发、高并发的访问模式要求重新设计数据库系统。这些模式为所有 AI 产品的架构设计提供了借鉴。
本文探讨了AI代理内存的现状与未来，指出随着多代理协作成为常态，内存需要从单个代理的私有状态中解放出来，成为可共享的独立资源。文章对比了Mem0、Zep、Letta、LangMem、Amazon Bedrock AgentCore Memory、Redis等主流方案，它们分别从身份、图结构、共享对象、可组合性、托管基础设施和数据架构等不同角度实现共享内存。尽管方法各异，但共同趋势是内存正获得独立身份和生命周期，并支持多代理读写，为构建通用AI内存奠定了基础。
文章探讨了构建软件工厂时最困难的问题之一：如何将人类语言描述的大型目标拆解为代理可执行的具体工作。作者梳理了五种逐步演进的方法：直接委派子代理（如 Claude Code、Codex）、可追踪任务系统（如 Gemini CLI、OpenAI Symphony）、工厂形态的工作结构（如 Warp）、结果关联的工作（如 Factory 的 Missions），以及动态工作图。作者指出，随着代理日益自主，系统本身需要围绕模型构建自己的智能来塑形、追踪和修正工作，这是软件工厂区别于普通代理框架的关键，也是当今 AI 领域最有趣创新的方向。
文章分析了当前兴起的"软件工厂"（Software Factory）产品的共同架构模式。作者指出，软件工厂并非能独立完成产品的巨型AI工程师，而是围绕AI工人构建的分布式系统，包含工作流、沙箱环境、权限、持久化状态、审查验证和人工检查点等。文章总结了六大架构模式：工厂拥有外层自动化循环；工人趋向短生命周期和隔离化；工作状态从Agent会话转移到外部持久化系统；厂商在集成式与开放式技术栈上分歧明显；验证成为工厂核心功能等。作者以Factory.ai、Warp和Vercel Foreman为例，探讨这一趋势对前沿AI实验室的战略意义。
文章探讨如何让人们对 AI Agent 承担更重要的工作建立信任。作者提出需要让 Agent 在工作过程中留下“回执”——即不可变的、有类型的工作工件（如证据、假设、评估、建议、审批等）。通过将“工作本身”建模为产品的一等数据，定义工件类型及其依赖关系，并强制 Agent 遵守这些结构（如建议必须基于评估、评估必须引用证据），系统能客观验证工作是否真正完成，而非依赖 Agent 自述。工件不可变可保留决策演变过程，且每个工件需指明所用上游工件的精确版本，从而形成可审计、可信任的工作链路。
