文章详细解读了 Earendil 和 Pi 社区发布的 Pi 1.0 及实验性新框架 Pi Durable。Pi Durable 专为构建长期运行、持久可靠、可动态改变、跨环境运行的 Agent 而设计。文章系统阐述了 Harness 的概念（Conversation、Agent、Tool、Execution Environment、Task），并重点介绍了其核心特性：崩溃恢复机制（基于 Checkpoint）、Exactly-once Submission 语义、多 Conversation 并发与 Fork、可插拔的 Extensions 体系、动态 System Prompt、Tool 的安全重放模型、Subagent 的轻量化实现、Hooks 拦截机制、Ownership Tree、前后台 Task 以及支持无限长对话的 Compaction。Pi Durable 秉承极简与可塑性原则，已超越普通 Agent Loop，具备了 Durable Workflow Runtime 的能力。
作者分享了用 Orca 编排多 agent 进行移动端开发一个月的实践经验。通过一个真实案例说明假前提如何导致整张依赖图建立在错误基础上，并提出 Graph Engineering 的三大支柱：图把长任务拆开跑起来（图是长出来的而非预先画完）、用 agent-device 真机验收等 anchor 防止假成功、以及通过闸门机制掌握改图权。作者强调失败信息比成功更有价值，三者结合才能构成反脆弱系统。
清华大学联合无问芯穹、上海AI Lab发布C2C（Cache-to-Cache）技术论文（ICLR 2026），彻底改变多智能体系统通信范式。传统Multi-Agent协作中模型需将高维思考压缩为文本逐字解码再传递，造成延迟、语义丢失和高昂Token成本。C2C通过轻量级神经网络（Neural Fuser）将模型A的KV-Cache直接旋转对齐后融进模型B的KV-Cache，并引入可学习门控机制动态决定各层吸收外部缓存的程度。实测推理速度提升2.0-2.5倍，问答准确率较单模型提升14.2%，比文本通信的Agent团队高5%。代码与论文均已开源，未来有望大幅降低Mixture-of-Agents调用成本。
本文介绍如何为多 Agent 团队搭建评估体系，以电商场景为例，通过五步流程：设计含陷阱的测试用例、保存 trace 回放协作过程、用结果/协作/决策三张成绩单分别评分、与单 Agent 及重试基线在同等预算下对比、将失败案例加入回归集。文章强调交接信息完整性、冲突解决、角色消融与协调增益等关键检查点，并给出可直接运行的最小 harness 代码示例。
文章探讨了构建软件工厂时最困难的问题之一：如何将人类语言描述的大型目标拆解为代理可执行的具体工作。作者梳理了五种逐步演进的方法：直接委派子代理（如 Claude Code、Codex）、可追踪任务系统（如 Gemini CLI、OpenAI Symphony）、工厂形态的工作结构（如 Warp）、结果关联的工作（如 Factory 的 Missions），以及动态工作图。作者指出，随着代理日益自主，系统本身需要围绕模型构建自己的智能来塑形、追踪和修正工作，这是软件工厂区别于普通代理框架的关键，也是当今 AI 领域最有趣创新的方向。
作者回顾了开源项目 LoopX 从诞生到爆火的全过程。LoopX 是一个面向长程 agent 的控制平面（control plane），核心假设是 LLM 上下文有限，长程 Agent 需要外置语义状态，通过 vision、goal、todo、gate、evidence 等抽象概念及状态机、replan 机制，让 Agent 在无人干预时稳定运行并持续产出。项目源自作者并行推进多个真实项目的痛点，经历了从 goal harness 到 LoopX 的演进，并借助 agent 自举迭代快速成长，登上 GitHub Trending 第一。作者展望未来构建由数百个 agent 组成的'数字团队'，让个人也能完成过去只有大型组织才能承担的复杂工作。
文章解析了 Codex 内部的四角色模型调用链（主模型、子 Agent、Review 模型、Compact），指出默认所有角色都用最贵模型导致成本过高。作者提出分级配置方案：主模型保留顶配负责规划决策，Review 和子 Agent 换用轻量平价模型，只需修改 config.toml 和 worker.toml 两个配置文件即可永久生效。文章还给出国产火山方舟的配置示例及其他省钱思路（Terra Max、Spark 高速模型等），强调好模型想清楚、便宜模型干活的分工思维可推广至未来 Multi-Agent 系统。
作者从 FDE（企业 AI 交付）视角，用同一份企业数据和 18 条压力测试对比了 Dify 与腾讯云 ADP 4.0。Dify 搭建快速灵活但生产环境交付环节仍需大量人工处理；ADP 4.0 将构建、接入、分发、治理统一进 AgentOps 平台，在高风险动作受控 Workflow、权限管理、知识库冲突处理、Skill 安全审查、Connector 接入及运行审计方面表现突出，还支持自然语言生成应用骨架和 Claw 开放式数据分析。结论是：个人快速搭建选 Dify/n8n，需要接企业系统、控权限、持续运维的交付项目更适合 ADP，能交付生产环境的 FDE 才能赚到企业的钱。
作者团队用 AI Agent 驱动前后端全流程开发（1个TL+6个子Agent），token成本高昂。通过AgentLens度量发现系统提示词、工具返回信息、历史消息是消耗大头。围绕'只看当前需要的上下文、减少无关上下文、减少重复上下文'三原则，实施了渐进式披露、CLI替代MCP、MCP子Agent化、长期记忆索引加载、多Agent拆分、工具白名单等10项优化，全流程降本50%~65%。
文章介绍了开源项目 awesome-agentic-ai-zh 提供的 AI Agent 学习地图，将学习路径分为两条：路线 A（CLI Power User）面向只想用好现成 Agent 的用户，学习 Claude Code、Codex、MCP、Skills 和工作流搭建；路线 B（Agent Builder）面向想开发 Agent 的工程师，需深入 Tool Use、Agent Framework、Memory、RAG 和 Multi-Agent。作者强调不要跳级学习，先补齐 Terminal、Git、API、JSON 等基础，普通人学好路线 A 已能解决大量实际问题。
本文介绍了如何利用 Hermes Kanban 插件构建一个多智能体协作的 SEO 文章生成流水线。作者创建了六个专业智能体，分别负责编排、策略制定、AI 搜索研究、源资料收集、写作和编辑。通过集成 DataForSEO 实时数据，实现了从关键词研究到内容发布的自动化流程，确保每个环节由专门的智能体负责，避免了单一智能体既当运动员又当裁判员的问题。
本文探讨了Agent从单一任务执行者演变为具备长期责任、领域分工和自主协作能力的团队的全过程。文章详细分析了Task Agent向Long-running Agent转变、Domain分化的必要性，以及如何通过CodexLoom解决Human Routing瓶颈，实现Agent间的高效协作与治理。
文章深入探讨了 Codex 作为 Multi-Agent 编排控制平面的进阶用法。文章详细解析了 Codex 的对象模型、项目绑定机制以及多种执行位置。重点介绍了六种原生 Agent 拓扑结构，从单线程到混合层级团队，并阐述了如何利用子 Agent 进行上下文隔离和并行工作，以避免上下文污染。
作者分享了重构 Hermes 多代理系统的经验，批评了当前将角色扮演误认为真正多代理系统的现象。文章提出了三种架构模式：一次性子代理、永久专家配置和群体，并强调了编排者的重要性。作者以 Wu-Tang Clan 成员命名不同职责的代理，展示了严格的权限边界和清晰的职责分配。
文章推荐了6个实用的Pi插件，包括必装的pi-agent-extensions、多代理协作的pi-agents-team、跨会话记忆增强插件、上下文工程工具以及连接Claude Code生态的桥梁插件，旨在提升Pi作为Agent Harness的扩展能力和效率。
本文是关于在 2026 年构建多 Agent 工作流的深度指南。文章对比了单 Agent 与多 Agent 系统的区别，详细解析了 Claude Code 的三种编排原语（子代理、团队、动态工作流）及六大核心拓扑结构（顺序流水线、协调者-工作者、并行发散、生成器-验证器、共享状态、辩论模式）。同时探讨了如何设计 Agent 间的通信、避免上下文污染以及处理系统失败模式。
作者分享了创立一人 AI 公司的经验，仅靠自身与 AI Agents 协作，在两个月内谈下超过 400 万台币的医疗影像与链上开发合约。文章探讨了 AI 在执行层面的优势，以及在处理复杂商业需求时的局限，指出现阶段核心在于“人机协作”而非“零人类参与”。作者利用自研的 TermHive 平台优化自动化流程，并强调人际沟通在建立客户信任中的不可替代性。
本文是一份关于 AI 智能体的综合指南，涵盖了从基础概念到生产级系统构建的全过程。文章深入解析了 Agent 的核心工作原理，如 ReAct 循环、任务拆解和上下文工程。同时，针对中级开发者，详细介绍了多代理系统的评估体系、记忆与知识管理、安全护栏设计以及四种核心设计模式，旨在帮助读者构建可靠且高效的 AI 应用。
本文是 Antonio Gullí 所著《Agentic Design Patterns》的读书笔记。作者不仅梳理了 AI Agent 从 Level 0（裸 LLM）到 Level 3（多 Agent 协作）的四个等级，还深入解读了 Context Engineering、Reflection（反思）、Memory 分层等核心设计模式。文章指出，大多数人在开发 Agent 时忽视了上下文工程和自我反思机制，并建议开发者先优化单 Agent（Level 2），再考虑多 Agent 协作。
本文指出构建 AI 产品的核心不在于选择模型，而在于架构设计。作者分享了 10 个实用经验，强调从工作流而非模型入手、重视检索优于微调、将提示工程视为系统工程、关注延迟优化、为智能体设置护栏、妥善处理记忆、建立评估管道以及优化成本。最终，多智能体系统将是未来趋势。
本文详细介绍了如何利用 Claude 构建一个多智能体系统。文章主张专家团队的表现优于单打独斗的通才，通过设立研究、生产、质量和分发四个专门的智能体，配合一个主编排器，可以实现高效的并行工作流。文中提供了从环境搭建、文件夹结构配置到首个研究智能体的系统提示词（Prompt）编写的完整实操指南。
Ruflo 是一个为 Claude Code 构建的“神经系统”和分层运行时，旨在提供 HNSW 向量记忆、100+ 专用 Agent 以及多智能体群集协调。文章详细介绍了其基于 MCP 的工具表面、联邦通信机制和自学习架构。同时，基于项目最新的 ADR 审计报告，分析了 Ruflo 在功能实现上的真实进展，指出了记忆层已可用而部分执行层（如神经网络预测、工作流运行时）仍处于存根状态的现状。
文章深入探讨了在构建复杂 AI 系统时，如何在“子代理”和“代理团队”两种架构模式之间做出正确选择。作者指出，大多数系统错误的按角色（如规划员、开发员）拆分，导致上下文丢失；正确的做法应是基于上下文边界进行拆分。Sub-agents 适用于独立的、需要隔离和并行处理的任务，专注于执行；而 Agent Teams 适用于需要深度协作、上下文共享和实时协调的复杂依赖任务。文章还总结了提示链、路由、并行化等 5 种核心设计模式，并强调了从简单开始、按需增加复杂度的原则。
这是作者 leon7hao 在 Build 03 活动上的演讲稿，介绍了项目 Lody。Lody 是一个基于本地优先理念的多端开发工具，旨在解决开发者在多设备间无缝切换及并行开发的问题。它利用 CRDTs 技术实现数据同步与版本控制，不仅解决了 Code Agent 的隔离与协作难题，还支持异构 Multi-agent 工作流，目标是成为 AI Native 团队的上下文同步层，保障数据隐私与所有权。
文章介绍了 Google Cloud 在 Next '26 大会上发布的 Agent Garden 及其包含的 12 个核心 Agent 蓝图。这些生产就绪的模板旨在解决多 Agent 系统的设计、编排和评估难题。文章详细剖析了 SDLC Suite（软件生命周期管理）、On-Brand GenMedia（品牌媒体生成）和 Invoice Processing（发票处理）三个核心架构，展示了如何利用链式架构、自适应学习框架和 LLM 评估机制来解决企业实际痛点，帮助开发人员快速落地 AI 应用。
文章介绍了 Google Cloud Agent Development Kit (ADK) 2.0 中的五种多智能体编排模式，旨在解决生产环境中智能体协作的难题。核心模式包括：混合图模式，结合确定性与 AI 驱动节点；协调者-专家模式，拆分单一“上帝智能体”为专注的专家系统；技能组合模式，通过 SkillToolset 实现跨域复用；跨语言流水线，支持多语言协作；以及协议标准化，确保上下文在不同智能体间无损传递。
文章深入探讨了多智能体系统背后的数学原理，解释了为何单Agent容易产出平庸方案（陷入“高概率吸引子”的盆地）。作者引用Cognition AI的实验，指出多Agent系统的核心价值不在于协同共享，而在于通过“上下文隔离”制造认知差异，从而打破思维定势。真正的Harness机制是通过改变约束条件，让不同Agent拥有不同的判断标准和认知框架。
文章回顾了作者在十个月前关于 Multi-Agent 系统的观点，并结合 Cognition 公司（Devin）在最近的实践经验，探讨了多智能体系统在工程实践中的实际应用。重点介绍了从“Prompt Engineering”到“Context Engineering”的转变，以及单线程写入、多线程智能辅助的协作模式。文章通过“Code-Review-Loop”案例，分析了独立上下文在代码审查中的有效性，指出模型通过消除上下文噪音和注意力分散，能更敏锐地发现逻辑错误和安全漏洞。
文章深度剖析了开源项目 Multica（GitHub 15.4k stars）的多智能体记忆系统架构。与普遍依赖向量数据库的方案不同，Multica 采用了基于 PostgreSQL 和 JSONB 的纯关系型数据库设计，通过 Issue、Skill、Agent Task Queue 等六张表实现状态管理、技能积累和工作空间隔离。作者详细梳理了任务从创建、快照生成到 Agent 执行的完整流程，并指出对于编码类任务，明确关联优于模糊检索，同时探讨了该架构在上下文持久化和跨工作空间记忆方面的局限性。
文章指出依赖单个AI Agent进行编程效率低下且容易失败，主要归因于对单一Agent期望过高及任务分解不足。作者通过对比单Agent与多Agent工作流在Codex Spark等平台上的表现，证明多Agent架构能显著提升效率、降低错误率。文章详细介绍了以Orchestrator（主管）和Subagents（执行者）为核心的“后厨”模式，并列出了五个实用模式，如并行执行和分步验证，展示了多Agent系统在扩展上下文窗口、增强流程控制和提升处理速度方面的巨大优势。
