上下文能塞 50 万 token,Agent 为什么还是记错中间结果?
文章探讨了即使大模型支持超长上下文窗口,Agent 在处理复杂任务时仍难以维护有效中间状态的问题。作者介绍了评测框架 ArbiGraph,该框架利用可执行任务图来测试模型的状态管理、依赖传递及抗干扰能力。实验表明,随着任务链路和分支复杂度的增加,模型准确率显著下降,强调上下文管理的核心在于维护可流动、可失效的计算状态,而非单纯扩容。
文章探讨了即使大模型支持超长上下文窗口,Agent 在处理复杂任务时仍难以维护有效中间状态的问题。作者介绍了评测框架 ArbiGraph,该框架利用可执行任务图来测试模型的状态管理、依赖传递及抗干扰能力。实验表明,随着任务链路和分支复杂度的增加,模型准确率显著下降,强调上下文管理的核心在于维护可流动、可失效的计算状态,而非单纯扩容。
文章指出大多数人在错误的层面修复 AI Agent 问题:模型失败时反复改提示词、换模型、加工具,却忽略了真正的问题是模型周围的环境——Harness。Harness Engineering 是构建围绕模型的系统,决定模型能看到什么、能做什么、记住什么、如何判定成功与失败。作者提出六大实践:将请求转化为带完成条件的任务契约;用渐进式披露提供项目地图而非塞满上下文;在模型与工具之间设置网关校验与策略授权;将记忆(事实、决策、状态、经验)移出对话外部存储;以可观测证据作为任务完成的门槛,优先用确定性检查。好的 Harness 能提升每一次运行的质量。
本文是 Claude 官方文章的译文,探讨在构建 agent 系统时何时应将子 agent 折叠进主 agent 循环。文章指出,配备 skill 的单一 agent 在质量、成本和延迟方面常常优于多 agent 设计。作者分析了大型组织构建 agent 的常见失败模式(上下文管理、子 agent 泛滥、Frankenprompt、延迟等),介绍通过渐进式披露 skill 和 MCP 工具的 agent 循环设计,并给出将子 agent 迁移为单循环的分阶段方法:构建任务完成评估、合并领域 agent、将子 agent 转为工具调用、用 skill 和工具替代子 agent,以及多团队协作的治理模式。
本期精选5篇高质量AI论文:1) AI智能体生态研究揭示协作产生强Allee效应,种群规模存在起飞阈值,对智能体安全有重要意义;2) BrickBench提出文本条件乐高组装的智能体基准,融合物理仿真验证;3) 思考惯性研究显示LLM被告知不思考时仍会输出显式推理,挑战一条指令关闭思维链的假设;4) 从形式化验证角度分析智能体自我改进的理论基础与极限;5) 提出工具型智能体的主动遗忘方法,可逆地整理上下文,累积输入token约减少50%,无需训练即可降低成本。
本文翻译自 Earendil Engineering 的《Prompt Caching In Agents》,系统讲解编程 Agent 中提示缓存的原理与实践。文章介绍了 KV 缓存的工作机制(prefill 与 decode 阶段)、缓存的两种存放方式(会话亲和性与分布式缓存)、前缀匹配对缓存命中的决定性作用,以及显式缓存与自动缓存的区别。还解释了为何修改工具定义会破坏缓存、TTL 过期导致短请求昂贵、缓存未命中的计费代价,以及 Pi 为何保持旧记录稳定而不激进剪枝,帮助读者在上下文、缓存复用、延迟与成本之间取得平衡。
作者分享了在番茄小说用 AI 写长篇的实践经验,指出大上下文窗口并不等于剧情逻辑连续性,核心在于状态锁、角色知识边界和改稿后的级联更新。文章深入分析了 5 个 GitHub 开源方案:oh-story(Codex 深度写手,追踪提交协议)、MuMuAINovel(中文 Web 工作台,可视化记忆管理)、Ani Book Skill(本地 YAML 工程化方案)、ainovel-cli(Go 语言多 Agent 引擎)、Webnovel Writer v6(Claude Code 插件),各自说明核心机制与实操避坑点。最后给出三个测试标准:道具连续性、角色知识隔离、改稿级联冲突检测。
文章推荐了一份13页的Agent记忆工程白皮书(民间整理,非Anthropic官方出品),将其拆解为5层记忆金字塔:工作记忆(上下文窗口)、情景记忆(交互日志)、语义记忆(知识图谱)、程序记忆(技能固化)和遗忘引擎(矛盾消解)。文章指出缺乏记忆分层的Agent会不断重复踩坑、成本高企,而引入该架构后Mem0的Token消耗降低90%、延迟降低91%,Snowflake准确率提升20%。核心观点是:不要迷信更大的上下文窗口,应把记忆做成可检索、可进化、可修剪的工程资产。
文章从工程视角系统讲解 Agent 概念:首先对比 AI 应用的三种形态——Chatbot(对话驱动)、Workflow(预设流程)与 Agent(ReAct 自主循环),分析各自优缺点及区分方法;随后给出最小 Agent 的循环伪代码,演示思考-决策-行动-感知的闭环机制;再梳理生产级 Agent 所需的八大能力模块,包括上下文管理、任务管理、记忆、连接器、Trace、容灾、编排与安全;最后探讨实际工程中三者混合使用的架构策略,如 Agentic Workflow、Workflow 包装为工具、前置路由分发等。
本文深度解读 omp 作者 Can Bölük 的《Harness Playbook》,提出 Agent Harness 是系统软件而非简单循环的核心命题。文章系统阐述 omp² 的架构蓝图:以唯一权威会话(DOM 树)解决 rewind/fork/resume 的状态一致性;沙箱只执行不决策;Convar 管值、Director 栈管行为的控制面设计;将模型兼容性作为结构化知识的推理层;精简工具名册以提升性能的深度内建工具;基于 RichText 流原语与 TLA+ 验证的渲染层;以及 Rust 核心 + Python 扩展的技术栈选择。文章认为该文将 Harness 工程提升为可推理的学科,同时指出其激进设计尚待落地验证。
本文介绍 pi-matt-pocock,一个将 mattpocock/skills 中适合工程协作的方法论适配为 Pi 持久化工作流编排器的 Pi package。它遵循最小工具暴露原则,仅提供管理命令和一个主要编排 tool,支持 idea-to-ship、hard-bug、triage、wayfinding、architecture 五条 route。相比纯 skills 方案,它通过按需加载 procedure 正文、将 route/procedure/phase 状态持久化到 session,解决了命名冲突、上下文膨胀与进度不可恢复问题。文章还延伸讨论了 skills 之外的架构设计空间,梳理了从扁平 skill 库到确定性状态机、按阶段拆分子 agent 等五种方案的权衡轴。
文章指出 Agent 可靠性的关键在于模型之外的确定性软件基础设施,即 Harness Engineering。作者提出构建弹性生产 harness 的 5 层方法:1)从模型优先转向系统优先架构,结构化工作流可将任务完成率从 31.7% 提升至 78.0%;2)实现持久化状态与检查点,避免长时间运行中丢失进度;3)通过角色分离(规划者、生成者、评估者)构建验证闭环;4)利用 hooks 和隔离运行时(如沙箱、网关)确保安全边界,防御提示注入;5)记录结构化追踪便于调试与自动化修复。文中结合 Google Antigravity、ADK 2.0、Gemini Enterprise 等工具给出实践建议。
作者发现验证Agent成员是否存活时,一句简单的「收到」竟消耗两万个token,原因是每次对话都要重新装配成员的身份、记忆、技能清单等。文章剖析了Agent成本的三层「过路费」结构:身份装配、上下文搬运和格式开销,指出七成token花在空驶而非思考上。作者提出三刀止损法:利用前缀缓存把不变内容前置、健康探针直连绕过人格装配、协作转手只传摘要。实施后成本降了一半以上,但同时也暴露出便宜诱发滥用、缓存惩罚变动等新问题,并引出本地化部署的机会成本与主权优势思考。