ActiveGraph: 长期运行 Agent 的连续性架构层
文章作者 Yohei 提出了 ActiveGraph 的概念，旨在解决长期运行 AI Agent 的状态连续性问题。作者回顾了 BabyAGI 的发展历程，指出当前 Agent 系统主要围绕“反应”构建，缺乏持续的状态管理。ActiveGraph 试图将任务、记忆、决策、证据等所有状态视为一个共享的演化图，从而实现 Agent 的持久化、自我修正和逻辑追溯，适用于需要严格推理过程的企业级场景。
相关文档
Harness Engineering: How to Build AI Agents That Actually Work
文章指出大多数人在错误的层面修复 AI Agent 问题：模型失败时反复改提示词、换模型、加工具，却忽略了真正的问题是模型周围的环境——Harness。Harness Engineering 是构建围绕模型的系统，决定模型能看到什么、能做什么、记住什么、如何判定成功与失败。作者提出六大实践：将请求转化为带完成条件的任务契约；用渐进式披露提供项目地图而非塞满上下文；在模型与工具之间设置网关校验与策略授权；将记忆（事实、决策、状态、经验）移出对话外部存储；以可观测证据作为任务完成的门槛，优先用确定性检查。好的 Harness 能提升每一次运行的质量。
Grok Bot Memory Engineering: How One Agent Learns With a Team
文章围绕 Grok Bot 新发布的 Team Bots 展开，深入分析团队级 AI Agent 的记忆工程。核心观点：团队 Bot 需要在共享学习与私有上下文之间划清边界。作者提出将上下文分为五类：实时源数据、团队技能、团队记忆、私有笔记和任务状态，并强调'可复用判断放记忆，易变数据留在源头'的原则。文章还提出记忆准入卡与审查机制的设计方案，包括准入门槛、外部账本、审查日期和评估流程，避免 Bot 在错误位置记住错误信息或把过时决策套用到新场景。作者同时说明这些流程是其提议方案，而非已验证的产品功能。
Grok Bot + Claude: 如何构建一个在你睡觉时工作的 AI 团队
文章提出不应把 AI 当作执行单个长任务的聊天机器人，而应构建一套完整的 AI 团队操作系统：以 Grok Bot 作为 Chief 协调者，配以 Researcher、Builder（Claude）、Reviewer、Reporter 四个专职角色，各司其职。核心要素包括共享工作区持久化任务状态、分层记忆系统、独立的验证流程以及人工审批边界，防止 Agent 在未经授权时执行不可逆操作。文章给出了具体的项目目录结构、Chief 角色的完整提示词，并以 GitHub issue 处理为例展示了从调研、构建、测试到审查的自动化协作流程，实现真正可审查、有证据支撑的自主工作成果。
Agent 高频题 03. 为什么要多 Agent：怎么拆、怎么通信、结果谁汇总
本文是 Agent 面试高频题详解第 3 题，围绕多 Agent 架构展开。作者结合 50 位作者、63 场面试的面经，系统梳理了六个追问方向：要不要拆、怎么拆、怎么通信、结果谁汇总等。文章指出单 Agent 在上下文膨胀、工具过多、提示词分支复杂、无法并行四方面会卡住；同时多 Agent 有 token 成本（约为普通对话 15 倍）、协调开销、信息丢失和错误传播等代价。文中总结了主从、流水线、并行分片、执行加审查、按意图转交五种结构，以及上下文、工具权限、可验收三类拆分边界，并对比 Skill、MCP、Workflow、SubAgent 等概念的适用场景，最后给出通信方式与面试应答要点。
给 AI 装上一条河，它会醒过来吗？
文章将一篇灵长类大脑神经科学的预印本、七世纪玄奘译出的《解深密经》与当今 Agent 架构并置对照，提出一个猜想：意识可能不仅关乎'位置'和'规模'，还关乎'时间上的选择'。研究发现面孔区以约每秒15次的节奏在'被意识到'和'被抑制'的表征间交替。作者类比唯识八识体系，指出今天的 AI 只有前五识和第六意识（推理），缺少第七末那识（恒常自我追踪）和第八阿赖耶识（恒转如瀑流的种子池）。文末给出一个玩具级'常驻之河' Agent 设计，包含种子池、节拍调度器、竞争选择、末那日志和熏习写回五个部件，探讨如何构建一个持续流动而非'每次调用从零开始'的系统。
别让 Agent 进同一个群聊：聊聊多智能体协作的底层框架
文章探讨多智能体系统的底层协作架构。作者指出，多个 Agent 被拉进同一群聊会迅速退化为互相吹捧与上下文失控，根源在于系统拓扑结构选错。文章分析两种模式：一是主从派发模式（Master-Worker），适合因果链强、有客观裁判的硬任务如写代码，但存在总管上下文雪崩的风险；二是黑板模式（Blackboard），基于发布-订阅机制，适合多角色、长链路、无单一裁判的开放式协同，但易陷入惊群效应与责任真空。作者提出终极形态是'宏观黑板、微观树'的混合架构：宏观层面用企业级共享事件总线承载粗粒度里程碑事件，微观层面各业务部门内部为紧凑的 Sub-agent 树，在独立沙箱中消化琐碎任务后仅交付确定性成果。
AI 长篇小说长期记忆方案盘点：5 个开源项目解决剧情失忆吃书问题
作者分享了在番茄小说用 AI 写长篇的实践经验，指出大上下文窗口并不等于剧情逻辑连续性，核心在于状态锁、角色知识边界和改稿后的级联更新。文章深入分析了 5 个 GitHub 开源方案：oh-story（Codex 深度写手，追踪提交协议）、MuMuAINovel（中文 Web 工作台，可视化记忆管理）、Ani Book Skill（本地 YAML 工程化方案）、ainovel-cli（Go 语言多 Agent 引擎）、Webnovel Writer v6（Claude Code 插件），各自说明核心机制与实操避坑点。最后给出三个测试标准：道具连续性、角色知识隔离、改稿级联冲突检测。
LoopX 1.2：会话会结束，工作不该结束
LoopX 1.2 正式发布，重点打磨个人工作区、长程状态与恢复能力，并推进多 Agent 团队的实验功能。新版本引入管家模式，可统一管理运行在 Codex、Claude Code 等执行器上的多个 LoopX Agent，提供独立设置入口和预览式配置。状态内核方面，Todo、lease、quota 等收敛到共享类型化边界，支持 Goal 验收合同、跨 Agent 任务接续与恢复。实验性能力包括团队计划与分工、受控 CLI/MCP 委派、产物复核与版本追溯。LHTB 基准测试显示平均 reward 提升 10.6%。文章最后致谢 40 位社区贡献者的 264 个已合并 PR。
System One Models: What Comes After Agentic Software
文章介绍 TypeSafe 发布的 Jev 模型，一种用于快速语义决策而非生成或长推理的 System One 模型，延迟低至 70ms 且成本低廉。作者认为这类模型可将小型语义智能分散嵌入应用的各个决策点，而非集中于 Agent 循环中，从而推动微推理时代的到来。这将使代码库中包含更多非确定性判断，同时应用层更明确地掌控编排控制流，推理模型则退居处理模糊和复杂案例的升级路径。文章还探讨了围绕微推理所需的基础设施（批处理、缓存、模型路由），并以自动驾驶和 Waymo 的 ML-primary 架构类比这种通用语义模型进入控制循环的新范式。
Harness Engineering: 2026年取代提示词工程的核心技能
文章指出，2024年的核心技能是提示词工程，2025年是上下文工程，而2026年两者已被吸收进Harness Engineering。88%的企业AI Agent项目无法上线，问题几乎不在模型，而在模型外围的执行层。作者详细阐述了生产级Harness的七层架构：工具编排（草稿-提交模式防止危险操作）、验证循环（制作者与检查者分离）、上下文与记忆管理、护栏（行为/数据/工具/运营四类控制）、可观测性等。并以Anthropic Claude Code质量退化为案例，说明问题源于Harness层而非模型本身，强调Harness设计才是AI Agent产品质量的决定性因素。
越来越值钱的互联：从存储到AI推理这条路，能让GPU少等一会儿，是被95%的人低估了的万亿市场
本文从GPU算力与内存速度不匹配的问题出发，深入分析AI推理中KV缓存的内存占用与复用机制，说明为什么给GPU扩容后计算芯片仍在等待数据。文章以Qwen3-32B为例量化KV缓存大小，比较本地缓存与远端缓存的传输开销，指出连接在缓存共享、跨机器传输中的关键作用。随后分析了铜互连与光互连各自的适用场景，介绍NPO/CPO技术路线，并以Marvell的CXL内存扩容控制器、交换芯片、信号调节芯片和Photonic Fabric为例，梳理连接芯片厂商的商业逻辑与验证进度，最后从客户成本账角度论证互联市场的价值，认为这是一个被低估的万亿级机会。
托管式 Agent 架构：为什么前沿实验室正在重构 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 是否必须来自模型提供商。