Harness Engineering 现在还处在很早期的阶段。软件工程发展了几十年,有成熟的方法论、教科书、最佳实践,新人进场基本都是站在前人踩过的坑上往前走。Harness Engineering 完全不是这样,现在能参考的经验少,能抄的作业也少,大部分东西都得自己摸索。 但早期恰恰是它的价值所在。一个领域一旦成熟,规则和最佳实践都定型了,新人进去更多是学习和执行,很难再抢到认知红利。而在早期，谁先动手实践、先踩坑、先总结出一套自己的方法论,谁就更有可能把这些经验沉淀成后来者绕不开的参考。 这个阶段最重要的不是等一套完善的方法论出现了再学，而是主动进场，一边做一边总结，把自己变成正在定义这套方法论的人之一。

Loop Engineering 最稳的上线方式不是一步到位无人值守。 而是分 3 层放权： L1：只报告 每天扫 CI、issue、PR，输出摘要，不改任何东西。 L2：小修复 只处理 lint、文档、测试快照这类低风险任务，必须开 PR。 L3：有限自动化 只在明确白名单里自动处理，遇到权限、支付、数据库、生产配置立刻停。 先让它看，再让它动，最后才考虑自动合并。

Loop Engineering 最容易被误解成： 让 Agent 一直自动跑。 它真正重要的地方，是目标定义。 以前你写 Prompt，是告诉 AI 这一次怎么做。 现在你设计 Loop，是告诉 AI： 什么算完成。 怎么验证完成。 失败了怎么办。 哪些动作禁止做。 什么时候必须停下来。 这要求的是管理能力。

爆肝整理，Graph Engineering 完整五步教程 👇👇 Loop Engineering 的继任者，把单线循环升级成并行图网络，一个窗口跑 1000+ Agent。 1：核心认知 单循环只能优化一个指标，容易掉进 Goodhart 陷阱。 Graph = 节点（一个Agent干一件事）+ 边（节点之间的数据依赖）。 把"先A再B"改成"A和B能并行就并行"，宽度决定速度。 2：找到真正的边 每次写"然后"时问自己：下一步真的需要上一步的输出吗？ 不需要 → 砍掉等待，直接并行。 你的"顺序执行"脚本，本质上就是个最寒酸的图——链式结构，一卡全卡。 3：上手实战 前置：Claude Code v2.1.154+，Pro/Team/Enterprise 开动态工作流。 粘贴一个prompt："审计 src/routes/ 下所有路由文件的权限校验，每个文件开一个Agent，分别验证，最多20个文件。" Claude 自动生成编排脚本，确认后跑起来。一个命令 → 十几个Agent并行 → 一份汇总报告。 中间结果存在脚本变量里，不污染你的会话上下文。 4：两个最容易翻车的地方： ① 图自说自话：让Agent检查自己的工作，它永远给自己高分。必须用独立节点验证，带独立上下文，检查真实信号（比如测试是否真的跑了）。 ② Agent互相踩脚：两个Agent同时写同一个文件=灾难。每个Agent必须有自己的隔离工作区（git worktree），结果合并策略提前定好。 5：六个可以直接套的图结构 - 安全扫描：每个文件一个Agent + 独立验证节点 - 深度研究：拆成多个角度并行搜索，Agent之间互相反驳再汇总 - 模块迁移：逐个文件迁移，测试做门禁 - 对抗性代码审查：小改动一票过，大改动全并行审计 - 定时生态扫描：存成模板，定时重跑 - 未知规模发现：并行探索，两轮没新东西就停 6：让图保持诚实 图本身不保证真相。必须锚定不可争辩的节点： - 真正跑过的测试（不是"应该能过"） - 基于证据的验证器 - Agent永远不能改的冻结规则 感谢 @0xCodila 的完整教程。