近期 X 上的热门议题，绕不开一个核心问题：怎么让 agent 更高效地自己把活干完，把人从"全程盯梢"的状态中解放出来。
Agent编排 #Harness工程 #LoopEngineering #GraphEngineering #无人值守
过去一年，X 上反复出现同一类抱怨：agent 一出错就重写 prompt，再出错就换模型，第三次出错就把 "IMPORTANT" 全大写加上，然后听天由命。Karpathy 在 这条推文 里把这种困境说穿了：agents、subagents、prompts、contexts、memory、permissions、tools、skills、hooks、MCP——这不是一件事，而是被揉进一句话里的多个层。问题几乎从来不在 prompt，大多数时候也不在模型，而在模型周围的那个系统——这也是 云栈社区 里开发者们反复讨论的结论。
三层架构：Harness、Loop、Graph
Harness（守护层）是围绕模型、让它能干真实活的一切：工具、记忆、权限、围墙、轨迹。最干净的定义是把模型从架构图上拿掉，纸上剩下的就是 harness。同一个模型放进带终端、测试和项目记忆的仓库里就能交付功能——权重没变，变的是 harness。
Loop（循环层）是有意识设计的"工作 + 反馈"系统：调用模型、运行工具、把结果喂回去、重复。它的核心规则只有一句：不要在置信度上循环，要在证据上循环。"agent 说它完成了"不是停止条件，测试全部通过才是。
Graph（图结构）解决多个 loop 之间的交接。节点是有边界的工作单元，边是真实依赖，状态是节点之间存续的东西。一个 loop 只是只有一个节点、一条指回自身的边的 graph。7 月 Peter Steinberger 在 这条推文 里一句"我们还在聊 loop 还是已经转向 graph 了"拿到 310 万浏览，Hamel Husain 随即写下《Loop Engineering Is Dead. Enter Graph Engineering》，这个词从此定型。
顺序很重要：先环境，再反馈，再流程。跳过任何一层，缺口就得由你自己补上。
Loop 工程有三条实践：在 agent 碰任何文件之前先写下什么叫"绿灯"，并且写一个在当前代码上会失败的测试；反馈要写明预期 vs 实际和已经走过的死路，一盏红灯本身只是判决，不是反馈；每个 loop 都要有出口——测试通过、相同结果出现两次、预算花完，三者任一触发就停。没有出口的循环不是坚持，是成本泄漏。
什么时候才需要 Graph
大多数任务不需要图，一个构建良好的 loop 能处理大部分真实工作。Shoopy 在 这条推文 给出的四问过滤：任务能否拆成相互独立的部分？不同子任务是否需要不同模型？写和审是否必须结构性地分开？你的 loop 是否已经撞到天花板？四个都答"是"才建图，缺一个就留着 loop。
真到了上图的阶段，三条铁律：一个节点只配一个动词，出现第二个动词就该拆成两个节点；每个 worker 有自己的上下文——共享一个上下文的四个 agent 不是一支团队，是一个戴了四顶帽子的 agent；已通过闸门的节点输出冻结为只读，失败时只带反馈重跑那一个节点。硬约束写在边逻辑里，不写在提示词里——提示词可能在长会话第 47 轮被忽略，边是代码，它不会忘记。
无人值守：把人从椅子上解放出来
Autonomy 有三级阶梯，每一级都让你离循环更远一步：手动运行 → /goal（跑到条件满足，由独立评估模型判定完成）→ /loop（按固定节奏重跑）→ Routines（跑在云端，笔记本可以关机，支持定时、webhook、GitHub 事件三种触发，见 Claude Code 官方文档）。顺序不能跳：先端到端盯完至少五次手动运行、读完每一个 diff、确认门真的能拦住该拦的东西，再放它定时跑。
设计一次无人值守运行，问的问题和优秀管理者把项目交给资深工程师然后去度假之前问的一样：它知道"完成"长什么样吗？有自我验证机制吗？边界在哪（沙箱、worktree、唯一允许推送的分支）？护栏是什么（轮次上限、花费上限）？在哪里产出结果、谁负责审批？
夜班交接式的任务书写法（来自 AQ 的指南）：一次会话一个任务，范围限定在一个专注工程师一晚能干完的量；"完成"必须可检查——"packages/api 所有测试通过、typecheck 干净"才算合格，"把测试修好"不行；小步提交、真实 commit message、在独立分支上干活；写明停止规则——被阻塞就把发现写进 NOTES.md 然后停，不要绕着阻塞点即兴发挥。
最关键的一条：护栏放在基础设施里，不放提示词里。prompt 是请求，一个困惑的模型或一段 agent 读到的恶意文本都能绕过它。凌晨三点还管用的护栏是上下文窗口绕不过去的那些：分支保护规则要求 CI 加人工批准才能合并、机器上没有生产密钥、git 身份只能推分支不能 force-push、权限用 deny 规则而不是全大写字母的叮嘱。Thoughtworks 2026 年 11 月的技术雷达也把 agent sandboxing 列为所有 agent 的默认项，见 Thoughtworks 技术雷达。
Addy Osmani 在 这条推文 把这层道理讲得最透：管理 agent 所需的技能与管理团队几乎一样。扩展 agent 数量的方式不是"监控得更多"，而是"需要监控得更少"——把大部分盯梢工作交给自评估、目标条件和新上下文的评审者，自己的注意力只留给决策。开出的会话数量超过自己能认真评审的上限，质量必然下降；度量"AI 写了多少代码"没有意义，要度量回滚和返工频率。
出问题时先问哪一层坏了
从上图顶端往下找你的第一个症状，那就是下一次修复。在终端和聊天间来回复制粘贴是 harness 缺工具；重复尝试干过的事是缺落盘记忆；"完成"必须你亲自检查才作数是缺能失败的检验；重试在同一错误上烧预算是缺反馈和出口；每一步都对但整体慢是缺真正的节点拆分；一处失败重跑全部是缺冻结；同一个错误每周回来一次，就要把教训归档到它所属的那一层。注意这张表里没有 prompt 这一行——prompt 里的话是愿望，结构才是保证。
三个陷阱
认知投降：测试全绿、命名合理就批准六百行 diff，这不是代码评审，是代码追认。评审每个 diff 的标准是"出了事你要被告警叫醒"。对抗方法是让 agent 反驳它自己的答案，重要判断绝不委派。
理解债务：图运转顺滑时会安静，安静让人感觉像进展，但仓库里实际存在的东西与你真正理解的东西之间的差距在按复利计息。每个图提交的 diff 都要读，定期抽查门是否真的抓住了该抓的——门会腐化。
过早建图：还没看过 agent 实际干完一次活，就先画出一张十二节点的图。先建一个 harness 和一个 loop，收集轨迹，只把真正配得上的东西形式化。底下没有能运转的 loop 的图，只是有组织的复杂度。
Harness 让 agent 有能力，Loop 让 agent 诚实，Graph 让 agent 有条理。下次 agent 说"完成了"的时候，问一问是哪一层替它说的。
参考来源
发表于 昨天 07:12
|
查看: 18|
回复: 0
/1 
