Agent 协作:从复杂任务分发到 Loop Engineering

Agent 协作:从复杂任务分发到 Loop Engineering本文分四部分:第 0 部分:哪些场景大概率用不上多 agent 和 Loop Engineering第 1 部分:复杂任务 prompt 输入后主 agent 决定分发 agent 的决策树/决策表第 2 部分:prompt → RAG → Harness → agent 工作流 → agent 间配合 → Loop Engineering第 3 部分:Loop Engineering 概念, closed/open loop优缺点何时使用第 0 部分:如无必要勿增实体在一切开始之前先泼盆冷水。在本文后面所有部分都会不断强调这个原则。每当有新概念出现“Harness Engineering”“多 agent”“Loop Engineering”很多人下意识地进入一个状态:看到一个任务第一反应不是怎么最快搞定它而是我能往里塞几个 agent、加多少harness、套几层 loop。进入到一种手里有个锤子看什么都像钉子的状态。一个改 typo 的需求起一个 orchestrator、三个 specialist、两个 checker再配一个每天凌晨自动触发、跨 run 记忆、带审计日志的 loop——用航母编队去钓鱼。场景与需求决定实现不是反过来。下面这些场景请收起多 agent 和 Loop Engineering:场景夸张的过度设计正常可以怎么做改一个 typo“我需要 tycker-agent reviewer-agent加个 verify loop 确保没改错”打开文件改了保存写一个排序函数“派 impl-agent 写, solo-tester-agent 验, fleet loop 跑到全绿”让 agent 一次写完人扫一眼格式化代码“文件变更触发 loop, agent 判断该不该 format”pre-commit hook规则确定无需判断部署到测试服“orchestrator 派 deploy-agent health-checker-agent闭环验证”CI/CD pipeline规则确定一次性数据清洗“agent 先理解数据 → 规划清洗策略 → 执行 → verify loop”写脚本或让 agent 生成脚本然后跑回答Python 怎么读 CSV“research-agent 多源调研 fact-checker 验证可信度”一次 prompt周报“content-loop:草稿 → critique-agent 评审 → 重写 → 打分”自己花五分钟写规律一眼能看出来:凡是规则确定、一次性、人能秒判对错的活不需要 agent 的判断力不需要 loop。给它们套 loop就像给自行车装自动驾驶——技术上能装但成本、复杂度、失败面都上去了收益非常低。三个止增阀门后面每个决策都要过一遍:该不该加 agent?—— 单步能成、无角色冲突、上下文装得下 → 不加。该不该引入 loop?—— 一次产出即可、人能快速判断、retry 成本高 → 不引入。该不该上 Loop Engineering?—— 低频、一次性、标准未定 → 不上。能用单 agent 别加 subagent能用工作流不用loop能用单次 loop 别上持续 loop能用简单工作流别造系统。 这条原则贯穿全文。不然多agent反而容易丢失原本上下文幻觉偏差导致结果不可用过度设计的loop也有可能烧掉过量的token导致账单高叠并且过度设计引入的不必要复杂度也会对系统的可观测性造成影响。下面才进入确实需要多 agent的场景。第 1 部分先了解一下agent是哪儿来的:复杂任务 prompt 输入后主 agent 决定分发 agent 的决策树/决策表当一个任务确实复杂(过了第 0 部分的阀门:多角色 / 大上下文 / 需要 maker-checker 分离)主 agent 才会进入分发模式。本部分讲:它怎么决定派不派、派给谁、subagent 从哪来、什么时候该预设新 agent。1.1 subagent 从哪来:类型是池子里的实例是当场新建的主 agent 派发 subagent是「从预设类型池里选 每次派发时新建一个实例」的混合机制不是凭空发明一种新 agent:Agent 类型(type)—— 预设的、注册好的池子。派发时只能从这个注册表里挑不能现场造一个新类型。常见类型:claude、general-purpose、Explore、Plan、claude-code-guide、statusline-setup加上用户在.claude/agents/下自定义的。Agent 实例(instance)—— 每次派发都是新建的。点一次 Agent 工具就开一个全新的子会话:独立的上下文窗口、独立的系统提示词、独立的工具集。子 agent 跑完把最后一条消息作为工具结果返回给主 agent(这条结果不直接展示给用户)。同一个类型可反复实例化每次都是干净的新会话。一句话:类型是池子里的实例是当场new出来的。还有一个关键认知:类型(type)和 能力(capability)是两回事——能力 90%(个人感觉, 存在夸张成分) 来自 prompt类型只决定三件事:默认人设、工具白名单、(有时)模型。一个开发 agent没被预先定义不等于不能开发;用general-purpose实例 一段开发 prompt 就能干。预先定义类型只是高频复用时的优化不是能用之前的前置条件。—— 这正是第 0 部分勿增实体的延伸:别动不动就预设新 agent type先用通用型 prompt 顶着。1.2 分发前的决策树:先过要不要加 agent阀门进决策表之前先过第 0 部分的阀门:任务来了 │ ├─ 单步能成、无角色冲突、上下文装得下? │ YES → 单 agent 一次做完(回第 0 部分) │ ├─ 任务有多个独立子任务可并行? │ YES → 加 agent,串行/并行分发 ↓ │ ├─ 需要专门人设 受限工具集(安全/合规)? │ YES → 加 agent,可能要预设新 type(见 1.5) │ ├─ 需要 maker 与 checker 分离(自己 review 不靠谱)? │ YES → 加 agent,写和验用不同实例 ↓ │ └─ 上下文太大,一个 agent 装不下? YES → 加 agent,分而治之 ↓只有命中后四条之一才往下走选型。1.3 选型只看两件事主 agent 挑类型时核心判断两点:要不要写文件?—— 决定能不能用只读 type(Explore/Plan)。要不要专门人设?—— 决定要不要新建 type还是用general-purpose prompt 注入人设。1.4 决策表(以一条流水线为例)以「需求→开发→单测→部署→集成测试kanban→修复循环」这条流水线为例:阶段角色要写文件?人设需求池子选择理由S0 需求摄入(写 SPEC.md)—是翻译/结构化general-purposeExplore 不能 Write;只是阅读可用 Explore但要把 spec 落盘就得 generalS1 代码实现maker是编码general-purpose池子里没有开发 agent用通用型 开发 promptS2 单元测试checker是测试general-purpose同上S3 部署—是(Bash/ssh)devopsgeneral-purpose(可选 devops 技能)需要 Bash 远程操作S4 远端测试 报 kanbanchecker是(Bashkanban)QAgeneral-purpose atlassian-mcp/jira-bug-fix 技能kanban 走 MCP 或技能S5 修复iterative maker是调试general-purpose systematic-debugging 技能调试方法论用技能注入1.5 什么时候需要预设新 agent(匹配失败决策树)主 agent 在池子里没找到完全合用的类型时按这个优先级处理——从最轻的干预开始不直接造 type:要写文件但选了Explore/Plan→ 这是选错不是真失败。建议换general-purpose。两者是只读的。池子里没有合用的人设→不用创建新 typegeneral-purpose 把人设写进 prompt。个人感觉可以覆盖 90% 场景。某个能力会高频复用、且需要固定人设 受限工具集(比如每个任务都要按内部规范写 Java)→可以创建一个新 type:在.claude/agents/name.md写 frontmatter(name / description / tools / model)落盘持久化。这是项目级的一次性定义不是每次任务临时造;产物留在磁盘供以后复用。任务是方法论/外部系统操作而非派活(调试流程、代码评审、Jira 操作、TDD)→尝试改用 Skill:systematic-debugging、code-review、jira-bug-fix、atlassian-mcp、test-driven-development。硬失败:需要的工具根本不存在(没配 kanban 的 MCP或没有部署凭据)→停下来上浮给用户。预设新 agent 的止增阀门:「高频复用 固定人设 受限工具集」三者叠加才落盘成新 type。一次性的人设写进 prompt 就够了。能用技能注入的优先使用技能注入。1.6 写 prompt:subagent子 agent 看不到父对话上下文所以每个 prompt 必须包含五要素:角色 / 输入(去哪读)/ 输出(产出什么、写到哪、返回什么)/ 约束 / 完成条件。prompt 质量基本决定子 agent 干得好不好。两个反模式(都违反第 0 部分):过度拆分:本来一个 agent 能干的活拆成三个 agent 传话每多一层就多一次上下文丢失和 prompt 重述。例:读测试结果翻译 agent根本没必要——让测试 agent 用结构化 schema 返回{passed, failures[]}主循环直接读省掉一整层。maker 兼 checker:写代码的 agent 自己 review 会太宽容。S1(maker)和 S2/S4(checker)必须用不同实例——这是加 agent 的正当理由之一。第 2 部分:AI 产出的演进 —— 提升可用性与可靠性的几条主线Loop Engineering不是凭空冒出来的新时髦而是 prompt、RAG、Harness、agent 工作流、agent 间配合一路探索过来的。这里只描述演进过程并不是一定某一层必然促成下一层或下一层必然依赖上一层—— 这些方向在时间上先后出现各自提升可用性与可靠性的某一面后续方向常在前面的能力之上发展但并非严格的前置条件。贯穿始终的目标只有一个:提升 AI 产出的可用性与可靠性。2.1 演进脉络(时间线 能力叠加非因果链)Prompt 让模型产出文本,但模型不知道且可能凭空编 │ ▼ RAG 外挂知识库,让产出有依据,降幻觉 │ ▼ Harness 给 LLM 套上运行时外壳:工具调用、权限、上下文管理、hooks、subagent 调度 │ —— 把模型变成可被工程化驱动的 agent ▼ Agent 工作流 在 harness 上,单 agent 用工具执行、自验证产出 │ ▼ Agent 间配合 在 harness 上,多 agent 分工:maker/checker 分离、并行、分治 │ ▼ Loop Engineering 在 harness 上,加自动触发 跨 run 记忆 持续闭环,直到达标注意:这是时间线 能力叠加不是因果链。比如裸 LLM API 不套 harness 也能做简单 agent 工作流;一个持续 loop 也可以单 agent、不分发。各方向常在前者之上发展但并非没有前者就没有后者。2.2 各方向在提升什么方向关键能力提升的维度演进中随后出现的方向Prompt让模型产出文本从无到有产出可用知识不足/凭空幻觉RAG外挂知识库产出有依据降幻觉可溯源产出仍不能行动Harness运行时外壳(工具/权限/上下文/hooks/subagent 调度)把模型变成可工程化驱动的 agentagent 工作流、多 agent、loop 多在它之上落地Agent 工作流tool calling能执行 自验证从只能说到能做 自检单 agent 上下文有限、角色冲突、自审不靠谱Agent 间配合maker/checker 分离、并行、分治验证独立于人设质量提升跑一次即停失败靠人不持续不记忆Loop Engineering自动触发 跨 run 记忆 持续闭环持续可靠、跨次延续、无需人驱动成本高(token 烧得快)需 stop condition 防失控2.3 Agent 间的几种配合模式(第 1 部分的上层抽象)第 1 部分讲的分发是其中一种补全全景:串行链:A 产出给 B, B 产出给 C。依赖明确简单可靠。(第 1 部分 S0→S1→S2→S3→S4 基本就是串行链)并行 fan-out:一个任务拆成 N 个独立子任务并行跑再汇总。省时但需独立无冲突。maker/checker 分离:A 写, B 验。验证不靠 maker 本人质量提升。第 1 部分 S1 与 S2/S4。pipeline 流水线:每项任务流过多个 stage无 barrier某项可在 stage3 时另一项还在 stage1。比每阶段全齐再下一阶段省时。orchestrator specialist(fleet):主 agent 拆活派给 specialist, specialist 还能用更小 subagent。第 1 部分主 agent 就是 orchestrator。止增提醒:这些模式不是越多越好。串行链能搞定就别上 fleet, maker/checker 分离够了就别叠 pipeline。每种模式都有编排成本和 token 成本(见第 0 部分)。第 3 部分:Loop Engineering —— closed/open loop优缺点何时使用本部分内容整合自rari0xwhrrari 在 X(推特)平台发布的 Loop Engineering 文章在其核心论述基础上做了整合与本地化。先记住第 0 部分的阀门:只在高频 有客观通过标准 需要跨 run 记忆时才上 Loop Engineering。低频、一次性、标准未定的任务留在第 1 部分的任务内闭环即可。3.1 核心转变大多数人仍在手动驱动 agent:敲一个任务 → 等一个回答 → 自己审 → 自己改 → 再敲。人还在循环里。下一步不同:你不只是 prompt agent而是设计一个 loop 去 prompt agent、检查结果、决定下一步、一直跑到工作通过为止。“你不应该再 prompt coding agent 了。你应该设计 loop 去 prompt 你的 agent。”—— Boris Cherny(Anthropic Claude Code 负责人):“我不再 prompt Claude。我有 loop 在跑它们 prompt Claude 并搞清楚该做什么。我的工作是写 loop。”Prompting gives an agent an instruction. Loop engineering gives an agent a job.(prompt 给 agent 一条指令, loop engineering 给 agent 一份工作。)3.2 是什么:5 阶段循环为 AI agent 设计可复用的反馈循环目标:从「一次尝试」走到「已验证结果」不需要人手动驱动每一步。Discover → Plan → Execute → Verify → Iterate——输出通过就交付(ship)失败就送回 loop。核心理念:不是一个完美 prompt而是一个持续改进输出直到达标的系统。3.3 成本:为什么多数人没真正建 loopLoop 听起来很美直到看到 token 账单。一个 agent loop 烧上下文极快:一个 medium coding loop:50K–200K tokens一个 fleet loop(orchestrator 若干 specialist):500K–2M tokens一个每日 scheduled loop:一周可达数百万 tokens每次 retry、每次自我修正、每次验证、每个 subagent 都花 token。Loop engineering 难不是因为想法复杂而是因为多数人负担不起让 agent 长时间自由跑。要让 loop 每天跑起来需要:便宜的输入/输出 token、大上下文窗口、tool calling、JSON 输出、高并发、足够上下文记住 loop 里早先发生的事。这正是第 2 部分说的agent 间配合是 loop 的基石的具体体现:stop condition 成本控制(廉价模型做验证、循环上限)是自动化的前提没有它们自动化 自动烧钱。3.4 两种形态:Single-Agent Loop vs Fleet LoopSingle-Agent Loop:一个 agent 跑整个周期(自己 discover/plan/execute/verify/iterate)像一个人改自己的草稿。适合聚焦任务、小范围、简单目标(草稿、bug 修复、研究摘要)。一个大脑一个 loop自我改进。Fleet Loop:给一个 orchestrator 主目标它把工作拆成块派给 specialist agent每个 specialist 还能用更小的 subagent 做窄任务。Example: Build a productivity app Orchestrator owns the mission ↓ ↓ ↓ Research Engineering QA Specialist Specialist Specialist ↓ ↓ ↓ Web Code Writer Test Writer Researcher Debugger Bug Tracker止增阀门:能 single-agent 别上 fleet——fleet 的编排成本和 token 成本远高于 single。只有任务确实需要多角色并行/maker-checker 分离时才上 fleet。3.5 两种类型:Open Loop vs Closed Loop(最重要的实践区分)Open Loop(开放):探索性。给 agent 一个宽泛目标让它自己找路。强大(agent 能发现你没指定的东西)但昂贵且 messy:优点:能发现意料之外的路径/方案缺点:可能试太多路径、烧太多 token、快速产出低质量、偏离真实目标、难控制多数人不应从 open loop 开始。Closed Loop(封闭):有界。人先设计路径, loop 自行跑但守在清晰规则内。一个 closed loop 有:清晰目标 / 定义好的步骤 / 每步后评估 / 停止条件 / 卡住时的交接点。优点:更便宜、更可靠、产出更干净缺点:需要人先设计路径灵活性低这是现今比较划算的版本。从 closed loop 开始等你的检查够强了再 open。第 1 部分流水线就是 closed loop(clear goalSPEC.md 验收标准 / defined stepsS0→S5 / evaluationS4 结构化 verify / stop conditionpassed or round≥3/ hand-off残留失败上浮)。3.6 6 个构建积木概念上每个 loop 是五阶段但实践上需要六个积木让它真正运转:积木作用落地情况(对照第 1 部分流水线)1. Automations心跳——不用手动记得跑 loop(每天早晨/PR 打开/文件变更/新工单/测试全过)❌ 第 1 部分目前手动触发2. Worktrees多 agent 改代码时不撞车各给独立 workspacebranch✅ 第 1 部分 1.7 并发编排3. Skills可复用项目知识不让 loop 每次冷启动✅ 第 1 部分 1.5 技能注入4. Plugins Connectors让 loop 碰真实工具(GitHub/Slack/Linear/Jira/数据库/Staging API)✅ 第 1 部分 1.5 MCP5. Subagents(maker/checker 分离)maker 和 checker 用不同 agent✅ 第 1 部分 1.4/1.66. Memory让 loop 跨 run 记住发生过什么⚠️ 第 1 部分只有任务内交接跨 run 缺对照可见:积木 2-5 在第 1 部分(任务内)已经齐了;Loop Engineering 相比任务内闭环真正新增的是Automations(积木1)和Memory 跨 run(积木6)。这就是第 2 部分说的第 1 部分是第 3 部分地基的精确落点。3.7 工具选型:个人开发者 vs 公司开发者怎么落地Loop Engineering 不是概念要靠具体工具栈落地。按规模分两档(同样遵循第 0 部分止增:能用轻的别上重的):个人开发者 —— 轻、便宜、单机积木工具选择Agent 运行时Claude Code(本地 CLI原生支持 subagent/skills/hooks/workflow)、Codex CLI、Gemini CLI、AiderAutomations(触发)Claude Codehooksscheduled_tasks/ 系统级cron/GitHub ActionsMemory(跨 run)本地 Markdown git、Obsidian、Claude ProjectsConnectorsMCP servers(GitHub/Jira/Slack 社区版)、本地脚本成本控制验证类用便宜的长上下文模型高档模型只用在重推理;循环上限设死公司开发者 / 团队 —— 治理、规模化、集成积木工具选择Agent 运行时Claude Code(团队配置/agent 定义共享)、或自建基于Claude Agent SDK / LangGraph的内部平台Automations(触发)CI/CD 集成(GitHub Actions/Jenkins/GitLab CI)、事件总线、工单 webhookMemory(跨 run)工单系统(Jira/Linear)、知识库(Confluence/Notion)、数据库、Claude Projects(团队共享)Connectors企业级 MCP / 内部 API 网关、SSO、审计日志治理(团队独有)权限边界、审计、成本监控(团队 token 预算)、人工审批门(high-risk hand-off)选型决策路径先问这场景真的需要 loop 吗(第 0 部分阀门 3.8 何时使用)。不需要就降级。再问token 预算扛得住吗。扛不住就缩小范围或换廉价模型。再问轻(个人)还是治理(公司)。从 closed loop 起步验证stop condition 够强再 open。从 single-agent 起步确实需要多角色再上 fleet。工具选型止增:能用 GitHub Actions 触发的别上事件总线能用本地 md 记忆的别上数据库能用 single-agent 的别上 fleet。规模和场景决定栈的重量。3.8 何时使用(强化止增阀门)该上 Loop Engineering 的场景每日自动处理 Jira 待办:定时拉待办 → 跑开发流水线 → 测试 → 回写工单(高频 触发器 跨 run 记忆)PR 打开自动 review:事件触发 → 多 agent 审查 → 评论/打分 → 失败回炉(高频 客观标准)文件变更自动测试:事件触发 → 跑测试 → 失败自动修 → 直到全绿(条件触发run until all tests pass)内容生产流水线:定主题 → 草稿 → critique agent 评审 → 重写 → 打分 → 过就发(迭代收敛到打分标准)不该上 Loop Engineering 的场景(降级到第 1 部分或更下)一次性脚本:写完跑一次就完 → 第 0 部分简单工作流 / 单 agent规则确定的部署/格式化/备份:CI/CD、pre-commit hook、cron(第 0 部分表)低频一次性任务:第 1 部分任务内闭环人发起一次跑完质量标准未定:stop condition 都没想清楚 → 别自动化先手动跑几轮把标准定下来一句话:Loop Engineering 适合高频 有客观通过标准 需要跨 run 记忆的重复任务。三者缺一降级。3.9 同一套骨架的不同应用Loop Engineering 的骨架是同一个 ——Goal → Action → Check → Fix → Repeat until done:Coding Loop:读 VISION/ARCHITECTURE → 规划改动 → 改代码 → 跑测试 → 失败就读错误修 → 过了就总结 → 停Research Loop:定问题 → 搜源 → 汇总 → 对源验证 → 比对冲突信息 → 综合 → 置信度达标就停Content Loop:定主题/受众/目标 → 草稿 → critique agent 评审 → 按评审重写 → 打分 → 过就发Sales Outreach Loop:定 ICP → 找线索 → 富集公司数据 → 按标准筛选 → 个性化消息 → 质量复核 → 发或上浮给人共同骨架:Goal · Action · Check · Fix · Repeat until done。差异只在每个阶段的目标定义和通过标准。但注意:只有高频重复的才值得做成持续 loop;低频的做成任务内闭环即可。附录 A:Loop Engineering 落地工具栈速查(完全由AI提供)第 3 部分讲了该不该上 loop、closed/open 与 single/fleet 怎么选;3.7 给了一张高阶选型表。本附录把那张表展开成具体工具清单,按第 3.6 节的六个积木逐项列,每项分「个人 / 团队」两档,并标注它落在 loop 骨架的哪一环。先过第 0 部分阀门再查这张表——工具是给已经决定要上 loop 的人准备的,不是上 loop 的理由。所有列出的工具仅作选型参考,不代表某一项是唯一解或必须采用。A.1 积木 1 · Automations(心跳/触发)loop 要自己跑,得有人/有东西定时或事件触发它。这是任务内闭环升级为 loop 的关键增量之一。档位工具一句话定位个人Claude Codescheduled_tasks(会话内定时)/ 系统级cron/GitHub Actions本机触发最轻;GitHub Actions 顺带白嫖云上运行环境个人n8n(自托管)/Pipedream拖拽式串多个 API,把拉 Jira→跑 agent→回写做成定时流团队GitHub Actions / GitLab CI / JenkinsPR 打开、push、标签事件触发的标配团队Temporal / Inngest / Trigger.dev长时、可重试、有状态的 durable workflow;loop 跑几分钟到几小时都不怕中断团队事件总线 工单 webhook(Jira/Linear webhook → 内部队列)真正的新工单自动进 loop需要事件驱动,不只是定时拉止增:能用 cron / GitHub Actions 定时拉就别上 Temporal。durable workflow 的价值在任务可能跑很久、可能失败要从断点续——单次几分钟跑完的 loop 用不上。A.2 积木 2 · Worktrees(并发隔离)多 agent 同时改代码不能撞车,各给独立工作区 分支。档位工具一句话定位通用git worktree(原生)一条命令开独立工作区,fleet 模式给每个 specialist 一份个人/团队Claude CodeEnterWorktree/ Cursor 多 workspace运行时内置的 worktree 调度,跑完可自动清理团队Graphite / Trunk叠加PR 堆栈管理,适合 loop 一次产出多个小 PR 的场景A.3 积木 3 · Skills(可复用项目知识)不让 loop 每次冷启动,把怎么干这活固化下来。档位工具一句话定位个人/团队Claude CodeSkills(.claude/skills/SKILL.md)项目级方法论/规范封装,按需注入,不占常驻上下文个人Claude Codesubagent types(.claude/agents/name.md)高频复用人设 受限工具集落盘成新 type(见 1.5)团队共享.claude/目录纳入 git / 内部 skills registry团队规范一次定义、全员复用A.4 积木 4 · Plugins Connectors(碰真实世界)loop 要操作 GitHub/Slack/Jira/数据库/Staging,靠连接器。档位工具一句话定位通用MCP(Model Context Protocol) 社区 server(GitHub/Jira/Slack/Postgres…)统一协议,agent 一处接入多源;Atlassian/Jira 有现成 MCP 与技能(见 1.5)个人Composio/ 本地脚本MCP server 聚合,一键装很多连接器团队企业级 MCP 网关 / 内部 API 网关 SSO 审计日志凭据集中托管、调用可审计,不让 agent 直拿生产库密码安全:连接器是 loop 触碰真实系统的手,也是最大的风险面。生产写操作务必走审批门或只读凭据。A.5 积木 5 · Subagents(maker/checker 分离)写和验用不同 agent,验证不靠 maker 本人。档位工具一句话定位个人/团队Claude CodeAgent 工具/Workflow 工具(pipeline/parallel)原生 subagent 派发 结构化 schema 返回,maker 与 checker 不同实例团队Claude Agent SDK / LangGraph / CrewAI / AutoGen / OpenAI Agents SDK / Google ADK自建编排框架,精细控制 maker/checker 拓扑、并发、重试通用廉价模型做 checker、高档模型做 maker验证是高频低推理活,用便宜长上下文模型省钱(见 3.3 成本)A.6 积木 6 · Memory(跨 run 记忆)loop 要记得上几轮发生了什么,不是每次从零开始。这是任务内闭环升级为 loop 的另一关键增量。档位工具一句话定位个人Claude Codeauto-memory(projects/.../memory/MEMORY.md索引)/Claude Projects文件式记忆,跨会话持久,轻量够用个人Obsidian / Logseqgit本地知识库,版本化,适合长期沉淀项目脉络团队工单系统(Jira/Linear) 知识库(Confluence/Notion) 数据库系统记录是组织记忆,loop 读写都落这里通用mem0 / Letta(原 MemGPT)/ Zep 向量库(pgvector / Chroma / Qdrant / Weaviate)给自建 agent 平台加可检索的长期记忆层A.7 横切:可观测性 成本治理(团队尤其重要)第 3.3 节点过成本:loop 烧 token 极快。个人可以看账单肉疼就停,团队必须有显式的可观测与预算手段,否则一个失控 loop 一夜烧掉季度预算。这块在第 3.7 的治理行只提了一句,这里展开。维度工具一句话定位Trace/可观测Langfuse / LangSmith / Phoenix(Arize)/ Helicone / Weave(WB)/ Portkey看 loop 每一步花了多少 token、哪个 subagent 失败、prompt 长什么样成本/预算LiteLLM / OpenRouter(模型路由 预算上限)/ 上述平台的预算告警廉价模型跑验证、贵模型跑推理,到预算自动停评估(verify 标准)自建 eval 集 promptfoo / DeepEval / Inspect把通过标准从 prompt 里抽出来,变成可回归的客观指标(对应 closed loop 的 stop condition)治理门high-risk 操作人工审批(配 Claude Code 权限/hooks 拦截)写生产、发外部消息、删数据前要人按一下A.8 选型速查(三步)先定运行时:个人优先 Claude Code / Cursor / Aider;团队要规模化才上 Claude Agent SDK / LangGraph 自建平台。再补两块短板:对照第 3.6 表,任务内已齐的积木 2-5 不用重买,真正要补的是Automations(积木1)和Memory 跨 run(积木6)——这两块决定它是不是loop而不是一次性工作流。最后上治理:团队才需要 A.7 的可观测/预算/审批门;个人靠账单 循环上限即可。全表止增:能用本地 md 记忆别上向量库,能用 cron 别上 Temporal,能用 Claude Code 原生 Agent/Skill 别自建框架,能用 GitHub Actions 触发别上事件总线。工具栈的重量,永远跟着第 0 部分的阀门走——不是反过来用一堆工具来论证我需要 loop。