AI Knowledge

外观

多 Agent、Memory 与 Loop 极简一问一答 ​

定位｜ 多 Agent、Memory 与 Loop 一分钟速答页。每章固定 10 题，只保留结论、机制、边界与验证关键词；单个回答控制在 10～60 秒。

1. 怎么使用 ​

本页重点｜ L1 概念 → L2 边界 → L3 原理 → L4 实现 → L5 工程 → L6 架构 → L7 复盘 → 误区、验证、证据强化。不会展开时，再进入正式主题或专项题库。

图：多 Agent、Memory 与 Loop 十题极简脑图

替代文本： 多 Agent、Memory 与 Loop从 L1 概念和 L2 边界，依次进入 L3 原理、L4 实现、L5 工程、L6 架构与 L7 项目复盘，再用误区、最小自测和证据边界三题强化。

图表加载中…

读图结论： 掌握 多 Agent、Memory 与 Loop 不能停在定义；先顺着七层链路说清机制与工程，再用误区、自测和证据边界确认没有虚假掌握。

2. 极简一问一答 ​

Q001｜什么才算多 Agent，它与一个 Agent 调多个工具有什么区别？

多 Agent 至少包含两个可独立运行决策循环的 Agent，它们具有可区分的指令、上下文、工具、权限或 State，并通过显式协议共同完成一个目标。一个 Agent 连续调用多个工具仍是单 Agent，因为决策责任和 Loop 没有拆开；同一模型生成多段角色意见也不自动构成多 Agent。是否拆分要看可并行性、上下文隔离、专门权限和独立验证是否能覆盖协调成本，而不是看角色数量。

Q002｜State、Context、Checkpoint、Event Log、Memory 和知识库怎样区分？

State 保存当前可恢复的结构化执行事实，Context 是本轮模型可见的有限视图，Checkpoint 是某一步的恢复快照，Event Log 记录发生过什么，Memory 是经过选择和治理、可在以后复用的信息，知识库则是组织认可且独立治理的外部知识。全量历史同时包含噪声、推测、隐私和过期内容，向量化只解决相似检索，不会自动提供来源、作用域、TTL、纠错、删除和 ACL，因此不能等同长期 Memory。

Q003｜多 Agent 系统里有哪些 Loop，谁决定继续与终止？

单个 Worker 内部运行“模型动作、工具执行、Observation、State 更新”的内循环；Orchestrator 运行任务分解、调度、合并和追加工作的外循环；任务完成后还可能有 Memory 候选提取、验证、合并和过期的整理循环。模型的 DONE 只是软信号，Runtime 必须用总步数、时间、Token、费用、并发、重复动作、权限、未决任务和最终结果断言硬终止，而且总预算必须向所有子 Loop 分配并汇总。

Q004｜多 Agent Runtime 最少需要哪些数据结构和控制？

Runtime 至少需要四类契约：Task Envelope 定义目标、输入、输出 Schema、工具权限、截止时间和局部预算；Result/Artifact 记录结构化结果、来源、版本、未知项和状态；Run State/Checkpoint 保存未决任务、父子预算、动作指纹和终止原因；Memory Item 保存作用域、类型、来源、置信依据、TTL、版本、取代关系和 ACL。控制面还要有工具白名单、超时取消、错误分类、幂等键、乐观并发、Verifier、Trace 与最终结果断言。

Q005｜系统调用暴涨且答案反复跑偏，怎样区分 Loop、Memory 和 Handoff 故障？

我先按 run_id 取消异常 Run、限制新任务并固定模型、Prompt、拓扑、工具、Memory 和预算版本。随后按任务分解与 Handoff 输入、Memory 候选和实际注入、Worker 动作与 Observation、Artifact 合并、父子预算与终止原因逐层找首次异常：重复动作和错误重派更像 Loop，错误或跨租户内容被稳定召回更像 Memory，交接后缺关键约束或重复询问更像 Handoff。修复后用原失败轨迹和注入样本重放，同时验证质量、调用数、延迟、费用和泄漏。

Q006｜Manager-as-Tool、Handoff、Group Chat 与单 Agent 怎样选？

路径稳定且副作用高时优先固定 Workflow；任务开放但单一上下文和权限足够时优先单 Agent。子问题可独立并行、需要上下文或权限隔离且最终责任应集中时选 Manager-as-Tool；需要专家持续接管用户对话时选 Handoff；只有参与者必须多轮互相回应、协商或批评时才用 Group Chat。切换必须用同模型、同工具、同权限和同总预算的任务集证明最终成功、墙钟时间或安全收益覆盖 Token、延迟、冲突和可观测成本。

Q007｜怎样设计并证明一个生产事故调查多 Agent 系统？

这是主文档中的示例设计：Orchestrator 根据告警拆出证据、变更和风险任务，多个只读 Worker 并行查询日志、指标与发布记录，用 Artifact ID 和来源交付结果，Verifier 检查时间窗、证据支持与冲突，Runtime 管理父子预算、Checkpoint、取消和终止；事故经验只有人工复盘或规则验收后才进入长期 Memory。它的亮点需要在同一脱敏事故集上与单 Agent 比较 End-State Success、Evidence Support、错误时间窗、危险建议、墙钟时间和成功 Run 成本；当前仓库没有实现和实测，所以不能声称效率或准确率提升。

Q008｜这个专题最常见的误区是什么？

常见误区有三类：认为 Agent 越多准确率越高，或只要有三个角色名就是多 Agent；让 Agent 用自然语言互传所有控制字段，或把共享 Python 字典当生产 State；“复杂任务就上多 Agent”，或把 Group Chat 当默认高级架构。

Q009｜怎样做最小自测？

最小自测分三步：不看文档，用 30 秒区分多 Agent、单 Agent 多工具和固定 Workflow；为 State、Checkpoint、Event Log、Memory 和知识库各写三个字段；画出 Worker 内循环、Orchestrator 外循环和 Memory 整理循环。

Q010｜回答这个专题时，证据边界是什么？

目前只有设计、Schema、双图、最小控制代码和故障演练证据，没有真实系统、用户、事故和基准结果。下一步应实现只读原型，构建脱敏历史事故集，再进行单 Agent、多 Agent 无 Memory、多 Agent 有治理 Memory 的受控对比。

3. 总结 ​

一句话记忆： 多 Agent 至少包含两个可独立运行决策循环的 Agent，它们具有可区分的指令、上下文、工具、权限或 State，并通过显式协议共同完成一个目标。

  • 多 Agent 至少包含两个可独立运行决策循环的 Agent，它们具有可区分的指令、上下文、工具、权限或 State，并通过显式协议共同完成一个目标。
  • 我先按 run_id 取消异常 Run、限制新任务并固定模型、Prompt、拓扑、工具、Memory 和预算版本。
  • 常见误区有三类：认为 Agent 越多准确率越高，或只要有三个角色名就是多 Agent。
  • 目前只有设计、Schema、双图、最小控制代码和故障演练证据，没有真实系统、用户、事故和基准结果。