2025 年初我刚开始做 AI 设计Agent MewDesign 时用的还是 Cursor。那时候我和 AI 的工作量大概是五五开。它帮我补代码、改文件我负责确认需求、检查结果、处理它做不好的部分再亲自把测试、提交和发布接起来。AI 已经很好用但研发流程仍然牢牢握在我手里。差不多到了 5 月有朋友推荐我试试 Claude Code。那是我第一次把持续 Coding 的主工作流从 IDE 搬到 CLI。刚开始并不习惯但适应以后我打开 IDE 的次数越来越少。再后来我开始高频使用 Codex。Agent 能连续调查一个真实项目、跨文件修改、运行测试、检查 Git 状态、处理 PR甚至跟踪发布结果。直到今天我已经很少再自己回去改动代码。这句话听起来很像「AI 把程序员替代了」但我的真实感受恰好相反我并没有退出研发只是把时间从亲自完成每一步转向决定什么值得做、怎样做、什么不能做以及用什么证据证明它真的做完了。回头看从 Cursor 到 Claude Code再到 Codex真正发生的变化不是模型一次能写多少代码而是我和 AI 之间的责任边界不断上移。前段时间我写过一篇文章解释 Loop Engineering 到底是什么。那篇文章里我把它概括成一句话不要再用一轮轮 Prompt 驱动 Coding Agent而是设计一套系统让系统去驱动 Agent。最近我真的把它做进了 MewDesign。它不是为了验证概念搭出来的 Demo而是一个 ARR 百万级、持续服务真实用户并产生真实收入的商业化产品。我把原来的研发流程拆成了 5 个 Agent Loop。它们会自己发现工作、调查问题、写方案、开发、Review、发布测试环境再把证据交回给我。但这五个 Agent 不会在群聊里互相开会。承载它们的也不是一个新的 Agent 框架而是一套由 GitHub、Skills 和 Harness 共同组成的工程系统。这篇文章不公开内部实现也不记开发流水账。我更想分享的是这套系统为什么会变成现在这样以及怎样从零搭出第一个真正能在商业项目里工作的 Agent Loop。01 - 从帮我写代码到替我推进研发在 Cursor 阶段AI 主要负责代码里的 Inner Loop理解当前文件、生成修改、修复局部错误。我则负责代码之外的 Outer Loop发现任务、确认需求、控制范围、判断结果、推进测试和发布。Claude Code 和 Codex 把 Inner Loop 做得越来越长但只要每一次状态变化仍然需要我回来回复一句「好的继续」我本质上仍然是整套流程的人工调度器。真正卡住研发效率的也逐渐不再是代码生成而是下面这些问题Agent 应该从哪里发现下一项工作哪些需求已经确认哪些还只是一种猜测修改到什么程度才算完成代码发生变化以后旧的 Review 和授权是否仍然有效任务中断后下一次怎样恢复而不是从头再来哪些动作可以自动执行哪些必须重新交还给人这些问题共同组成了代码之外的 Outer Loop需求、状态、权限、验证、发布和反馈。所以我做 Loop Engineering不是为了让 Codex 一次写更多代码而是为了不再由我亲自推动每一个步骤。系统应该知道当前处于什么状态、下一步允许做什么、需要调用哪一种 Skill以及凭什么继续。02 - 很多 Multi-Agent本质上只是角色扮演常见的 Multi-Agent 系统大概是这样的Planner Agent 负责规划→ Coder Agent 负责写代码→ Reviewer Agent 负责检查→ Manager Agent 负责决定是否完成看起来分工明确实际上经常有几个问题。第一个问题角色不同不代表判断独立如果几个 Agent 使用相同的模型、相似的上下文和同一份错误前提那么 Reviewer 很可能只是换一种语气重复 Coder 的结论。给模型加一句「你现在是一个严格的 Reviewer」不会自动产生真正独立的验证。真正的独立来自不同的证据来源代码 Diff、测试结果、真实页面、运行日志、权限边界和用户验收而不是 System Prompt 里的不同职位名称。第二个问题Agent 互相传话会不断损失上下文很多 Multi-Agent 编排喜欢让 Agent A 总结给 Agent BAgent B 再总结给 Agent C。每一次转述都在压缩信息也在加入新的解释。最后执行者拿到的可能已经不是原始需求而是第三手摘要。如果原始 Issue、决策记录、代码状态和验证证据本来就存在于一个公共系统里Agent 为什么不能直接读取事实而要听另一个 Agent 转述第三个问题多 Agent 会把不确定性放大成共识一个 Agent 猜错了另一个 Agent 沿着它的前提继续推导第三个 Agent 再对结果做形式上的 Review。最后三个 Agent 得到了「一致结论」看起来很可靠。但这不是共识只是一条错误被传了三遍。第四个问题Agent 数量不是系统能力增加 Agent 很容易增加以后也很容易做出一张复杂的架构图。但更多 Agent 同样意味着更多 Token、更多延迟、更多重复上下文以及更多需要协调的中间状态。如果任务本身没有明确的权限隔离、并行价值或独立验证需求一个 Agent 完全可以做完就没有必要为了 Multi-Agent 而 Multi-Agent。所以我现在判断一套 Multi-Agent 设计是否合理不会先问「用了几个 Agent」而会先问这些角色是否拥有不同的触发条件、上下文、权限、完成标准和停止条件如果答案是否定的那它们大概率只是几个不同名字的对话窗口。03 - 我的 5 个 Agent 彼此不聊天MewDesign 的 5 个 Agent Loop大致对应研发过程中的 5 种责任这里的 Loop 不是五个常驻在线、轮流发言的 Agent而是五个会被特定状态唤醒、完成一段工作后停止的独立循环。Agent Loop核心责任它没有的权限Issue Planner调查问题形成可确认的方案不能直接写代码Approved Builder实现已经确认的方案不能擅自扩大范围Preview GuardianReview 当前代码并维护问题状态不能随意修改别人的分支Test Release Controller把确认过的版本发布到测试环境并验证不能发布正式环境Master Reconciler整理验证证据和本地工程状态不能自动合并正式分支这五个角色不是因为我喜欢数字 5而是因为它们之间恰好存在清晰的权限边界。Planner 可以读很多但不能写代码Builder 可以写代码但只能执行确认过的范围Guardian 可以否决但不能借 Review 之名重做产品Test Controller 可以操作测试环境却不能碰生产Reconciler 只负责证明事情已经收尾不能把「看起来做完」变成「自动宣布完成」。它们之间也不需要直接对话。Planner 不会打开另一个 Agent 会话对 Builder 说「我分析完了现在轮到你。」它只会把方案和状态写回 GitHub。Builder 醒来以后也不会相信 Planner 的一段口头总结。它会重新读取 Issue、方案版本、当前代码和最新 Master再判断方案是否仍然成立。Guardian 不会相信 Builder 说「测试都过了」。它读取的是当前 PR Head、实际 Diff、CI 和测试证据。每个 Agent 都面向同一个外部事实系统工作而不是面向另一个 Agent 的记忆工作。这也是我认为更合理的 Multi-Agent 形态Agent 之间不交换信念只交换经过持久化的状态和证据。所以我只会在不同阶段确实需要不同上下文、权限、独立证据或异步等待时才把任务拆成多个 Agent。没有这些边界时一个 Agent 完全可以做完增加角色只会增加上下文转发和协调成本。04 - 为什么我最后选择 GitHub设计这套系统时我可以新建一个数据库设计一套工作流表再做一个 Agent 调度后台。但我最后没有这么做。因为对于软件研发GitHub 本身就是一个非常成熟的人机协作系统。Issue 是天然的上下文容器一个好的 Issue 里本来就应该包含为什么要做当前有什么问题用户受到什么影响讨论过哪些方案哪些事情不在本次范围最后做了什么决定。这些信息同时适合人和 Agent 阅读。对团队成员来说Issue 是协作入口对 Agent 来说Issue 是一份会持续更新、不会随着对话结束而消失的任务上下文。相比把所有背景塞进一次 PromptIssue 还有一个很大的优势它允许人随时介入、纠正和补充而且每一次变化都有记录。GitHub 已经具备状态机的骨架Issue 不只是需求文档。Label、Project Status、Comment、PR、Review、Commit SHA 和 Actions 共同描述了一个任务现在处于什么状态再加上明确的转移规则它们就能构成一套研发状态机待处理→ 方案待确认→ 开发中→ Review 中→ 等待测试授权→ 测试已验证→ 等待正式发布→ 完成状态转移也天然伴随着事件有人确认了方案、PR 有了新提交、CI 通过、Review 出现 Blocker、测试环境完成验证。Agent 不需要自己「记住」任务走到了哪里。它只需要在每次运行时重新读取 GitHub 的真实状态再按照明确的转移规则判断有没有自己可以处理的下一步。GitHub 同时适合人与 Agent 协同如果状态只放在 Agent 专用数据库里人就很难理解它为什么做出某个决定如果状态只存在聊天记录里其他团队成员又无法参与。GitHub 正好位于中间人可以在熟悉的 Issue 和 PR 里讨论、确认、否决Agent 可以通过结构化接口读取和写入评论和 Review 天然形成审计记录Commit SHA 可以精确绑定一版代码Actions 可以提供机器验证证据通知、权限和团队协作能力都已经存在。我不需要为了 Agent 重新发明一套研发协作方式。更合理的做法是让 Agent 学会进入人类已经在使用的系统。GitHub 让任务可以恢复Agent 任务会中断模型会忘记上下文也会被压缩。但只要关键状态已经写回 Issue、PR 和 Commit下一次运行就可以重新构建现场方案是否确认、代码在哪个分支、当前 Head 是什么、哪些问题已经修复、测试环境是否验证过。这比「让 Agent 拥有更长的 Memory」可靠得多。我一直很认同一句话Agent 会忘但工程记录不会忘。现在我觉得还可以再加一句对研发 Agent 来说GitHub 就是它和人类共同拥有的长期记忆。05 - Skills 和 Harness 是怎么在真实项目里工作的如果只有 GitHub 状态和几个定时触发器这套系统最多算一个任务调度器。MewDesign 是一个持续在线的商业化产品。它的研发不只有「写代码」一个需求会经过调查、方案确认、实现、Review、测试、构建、发布、运行验证和团队同步线上问题还可能继续进入日志、数据或 Agent 运行轨迹的调查。这些环节面对的上下文、工具、权限和风险完全不同。把它们全部塞给一个拥有所有权限的 Agent再配上一份巨大的 System Prompt并不会得到一个全能工程师只会得到一个很难知道自己何时越界的模型。所以我没有写一个万能 Skill而是把长期经验拆成了很多职责单一的 Skills协作 Skill 管 Issue、PR 和任务状态测试 Skill 负责根据改动选择验证方式发布 Skill 只处理发布前提、授权和执行运维 Skill 默认只读取运行状态日志、数据库和 Agent 运行时也各有自己的调查边界。一次任务怎样在 Skills 之间接力以测试发布为例。「把这个版本发到测试环境」听起来只是一条命令在我的 Harness 里却会被拆给几个不同的 Skills。协作 Skill 先确认需求、PR、准确版本和影响范围并检查 Review、测试与 CI。随后发布 Skill 才接手环境确认和执行授权而且授权只绑定当前版本代码再次变化旧授权就自动失效。发布入口返回成功也不是终点它只能证明请求被接受。运维 Skill 还要以只读方式确认实际运行版本、服务健康和外部接口出现异常时再把限定好的时间窗口和问题范围交给日志或数据库 Skill而不是由发布 Agent 临时越权调查。只有这些证据都通过协作 Skill 才会更新 GitHub 状态并同步结果。没有任何一个 Agent 可以凭一句「我觉得完成了」跳过下一层验证。Skill 固化的不是知识而是操作契约我这里说的 Skill不是一段写着「你是一位资深工程师」的角色设定而是一份可以被反复调用、持续修改的操作契约。工作类型Skill 真正固定下来的东西需求与方案必须读取哪些事实、怎样写 Scope 和 Non-scope、什么歧义必须交还给人代码 Review必须检查哪一版 Diff、怎样判断测试和 CI、什么结论可以阻塞继续推进发布环境、版本和授权如何绑定哪些前提缺失时绝不能执行运维默认只读怎样区分发布中、发布完成和真实故障什么动作需要再次确认日志与数据查询时间窗、最小必要范围、脱敏方式以及什么时候只能给出假设它们通常都会回答六类问题适用范围、必读上下文、允许使用的工具、权限边界、完成证据和停止条件。但真正重要的是规则会随着事故不断升级。我遇到过发布请求已经成功返回但运行环境还没有完成更新于是「请求成功不等于结果成功」成为发布 Skill 的强制验证链。我遇到过授权以后代码继续变化于是授权必须绑定具体版本版本漂移后自动作废。我遇到过任务中断后重新运行于是所有关键动作都要可恢复、可判重不能重复创建、重复发布或重复通知。我也遇到过调查问题时证据面不断扩大于是日志和数据库默认从聚合、只读、最小范围开始而不是先把所有原始信息交给 Agent。踩过一次的坑如果只留在我的记忆里下一个 Agent 还会再踩把它写进 Skill并配上可以验证它的工具和测试它才会变成系统能够复用的工程经验。Harness 不是工具箱而是责任路由器只有 Skills 仍然不够。文档里写着「不要碰生产」不代表一个拥有全部权限的 Agent 就天然安全。Harness 一方面为 Agent 提供代码库、GitHub、测试、浏览器、日志、数据和发布能力另一方面也决定当前任务只能加载哪些能力谁有权改变哪一类状态以及什么时候必须切换到另一个专业 Skill。发布 Skill 不应该自己写 SQL数据 Skill 不应该顺手重启服务运维 Skill 不应该替协作 Skill 合并代码。职责分开以后每个 Skill 才能拥有更小的权限、更清楚的输入输出以及真正独立的停止条件。我现在会用下面四层来理解整套系统GitHub保存任务现在处于什么状态Loop决定什么时候运行、什么时候停止Skill规定这类工作应该怎么做Harness提供工具和环境并把权限、验证、恢复做成硬边界每个 Loop 唤醒后不是从一份巨大的万能 Prompt 开始而是根据当前状态加载对应的 Skills。Harness 负责把任务路由给正确的能力让它在允许的范围内行动再把结果和证据写回 GitHub。这也是为什么同一个模型放在普通聊天框里和放进一套成熟 Harness 里会像两个完全不同的执行者。模型能力决定它能想到多远Skills 和 Harness 决定它能不能在真实项目里稳定地把事情做完。五个 Agent Loop 是最容易被看见的外壳。真正需要长期积累的资产是下面那些不断被修正、被版本化、被真实事故检验过的 Skills、工具和约束规则。06 - 手把手搭建第一个 Agent Loop如果你也想搭一套 Loop Engineering 系统我不建议一开始就复制五个 Agent。先挑一段边界最清楚、结果最容易验证的工作只搭一个 Loop。等它能够稳定运行再沿着真实的责任边界拆出下一个。以前我通过聊天推动 Codex你先分析一下→ 好的开始改→ 再 Review 一下→ 修复这个问题→ 可以发布测试环境了要把这段对话变成一个可以反复运行的 Loop至少要完成下面六步。第一步定义 Trigger先写清楚什么变化会唤醒 Agent。触发条件应该是机器可以读取的事实例如 Issue 进入某个状态、PR 出现新的 Commit或者测试授权绑定到了当前版本。不要把「有空时看看」或「觉得差不多了就继续」当成 Trigger。无法准确判断的触发条件只会把人的犹豫搬进自动化系统。第二步指定 Context列出 Agent 每次启动都必须重新读取的事实来源。它不应该依赖上一次对话还记得什么而应该从 Issue、方案版本、代码、PR、CI 和最新验证记录中恢复现场。这里最重要的不是塞进更多上下文而是确定谁才是事实来源。相同信息如果在聊天记录、文档和 Issue 里各有一版Agent 只会更困惑。对代码任务来说Context 还包括 Base、Head 和分支来源。文件 Diff 只能说明改了什么不能说明这组修改从哪里来、准备进入哪里。第三步划定 Authority明确 Agent 可以改变什么也要明确它绝对不能改变什么。例如Review Loop 可以读取整个 PR、提交 Review、更新问题状态但不能顺手修改开发分支测试发布 Loop 可以操作测试环境却不能因为测试通过就继续发布生产。我会要求方案同时写清 Scope 和 Non-scope。否则 Agent 很容易为每一项额外修改找到合理解释最后却把一个小需求做成跨模块改造。第四步设计 Verifier为每个动作指定可以验证结果的外部证据。测试命令退出为零、CI 绿色、页面实际可用和线上版本完成切换是四种不同层次的证据不能互相替代。Verifier 最好使用执行者没有用来得出结论的证据。否则所谓验证很可能只是让 Agent 再肯定自己一次。第五步定义 Stop提前列出必须停止并交还给人的情况例如需求存在歧义、方案版本已经变化、PR Head 与授权版本不一致、修改越过 Non-scope或者任务触及生产数据和资金逻辑。一个可靠的 Loop 不只是知道什么时候继续也必须知道什么时候闭嘴。第六步约定 Write-back最后规定 Agent 要把结果写回哪里以及至少留下哪些证据。下一次运行应该只依靠这些持久化记录就能判断上一次做了什么、做到哪一步、为什么停下。在 MewDesign 里它们会变成可以被系统读取的状态变化一个符合条件的 Issue 进入待处理Planner 才会开始调查我确认了某个方案版本Builder 才获得实现权限PR Head 发生变化Guardian 才重新 Review当前版本通过 Review 和 CI并获得精确授权Test Controller 才能发布正式分支被人工合并以后Reconciler 才能做收尾。每个 Agent Loop 都可以抽象成同一个结构Trigger什么状态变化会唤醒我Context我必须重新读取哪些事实Authority我被允许改变什么Verifier什么证据说明动作成功Stop出现什么情况必须停止Write-back结果写回哪里例如一个最小的 PR Review Loop 可以这样定义TriggerPR Head 发生变化并进入待 Review 状态Context原始 Issue、已确认方案、Scope / Non-scope、Base、Head、Diff、CIAuthority提交 Review、标记 Blocker、更新 Review 状态不能修改开发分支Verifier结论绑定当前 Commit SHA并引用代码、测试或页面证据Stop需求不清、Head 再次变化、出现超出权限的高风险问题Write-back把结论写回 PR并同步 Issue 状态这已经是一个完整的 Loop。它不需要另一个 Agent 给它派活也不需要永远保持一段对话。每当触发条件成立它重新读取事实、在权限内行动、留下证据然后停止。这六个问题比给 Agent 写一段很有气势的角色 Prompt 更重要。因为 Prompt 解决的是「它应该怎么想」状态机解决的是「它现在能不能做」。驱动系统的也不再是人的下一句话而是共享状态发生了变化。07 - 人不是退出 Loop而是从执行者变成授权者做自动化时经常有人把 Human in the Loop 理解为「Agent 做完以后让人点一下确认」。我觉得这还是太粗了。人的价值不是给 Agent 的结果盖章而是在高后果的状态转移上拥有最终决定权。在 MewDesign 里我保留了几类明确的人类 Gate。方案 GateAgent 可以调查和提出方案但只有我确认了某一个具体版本Builder 才能开始实现。如果方案后来被修改旧授权自动失效。这样可以防止 Agent 拿着一句模糊的「可以」去执行已经变化的需求。代码版本 Gate测试授权会绑定到具体的 Commit SHA而不是一句宽泛的「这个 PR 可以发」。只要 PR 又有新提交代码已经不是我确认过的那一版旧授权就不能继续使用。生产 Gate测试环境可以在边界清楚、证据充分时自动推进但正式环境仍然需要独立确认。支付、权限、数据库迁移、生产数据和流量切换等高风险工作也不会因为 Planner 判断方案清楚就自动进入实现。同样的边界也适用于整套 V1。它不会自动决定存在产品歧义的需求不会自动执行数据库迁移、生产数据写入或流量切换也不会自动合并正式分支、发布生产环境或者在证据不足时宣布完成。这些不是系统暂时遗漏的功能而是我有意保留的责任边界。它们只会随着验证能力逐步开放不会因为模型能力变强就一次性交出去。这套设计并没有减少人的权力而是减少了人必须亲自执行的步骤。我不需要守在终端前告诉 Agent 下一条命令是什么但我仍然决定什么值得做、哪一版可以进入共享环境、什么时候可以承担生产后果。Agent 的权限应该来自长期可靠性而不是一次漂亮 Demo。08 - Loop Engineering 的核心不是循环而是闭环表面上看这套系统自动化的是 Issue、代码、PR 和发布。但我觉得更准确的说法是它自动化了状态和证据的流动。Planner 把需求证据写回 GitHubBuilder 从共享状态中重新读取它再把实现证据写回去Guardian 和 Test Controller 也遵循同样的方式。没有 Agent 直接把结论交给下一个 Agent所有交接都先变成可读取、可核验的工程记录。每个角色只完成自己的一小段却共同形成了一个可以持续运行、可以中断、可以恢复、也可以追责的闭环。所以现在如果让我重新解释 Loop Engineering我会这样说Loop Engineering 不是让 Agent 一直跑而是把目标、状态、权限、证据和停止条件设计成一个可以反复运行的系统。以前我常说AI 做执行人做判断。现在我觉得还要补一句GitHub 保存共同上下文状态机决定谁可以继续证据决定事情是否完成。MewDesign 的这套实践不是一个通用答案但它至少让我确认了一件事未来的软件工程不会只是「一个人带着一个更强的编码 Agent」。它更像是人和多个受约束的 Agent共同工作在同一套共享、持久、可审计的工程状态上。而真正值得设计的也从来不是 Agent 之间该聊什么。是它们各自该负责什么以及什么时候必须闭嘴。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】