夜雨聆风最近一直在梳理 Agent，我有个感受越来越强：很多听起来很新的词，最后都会回到一些很老的工程问题。
企业真要把 Agent 放进业务流程，第一关未必是模型够不够强，而是组织自己的工作系统够不够清楚。
这两天连续看到几个相关讨论，越看越觉得它们其实在讲同一件事。
一边是 Rahul 总结的 20 种 Loop 模式：生产级 AI 系统很少只靠一次模型调用，更多要靠观察、评估、行动、再调整。
另一边是 Daniel Miessler 对企业 AI 准备度的提醒：很多公司想用 AI，却说不清目标、工作流、决策、团队和成本。AI 再强，也很难知道该优化哪件事。
放在一起看，问题就从“Agent 怎么循环”往外推了一层：
企业想让 AI Loop 跑起来，先要把目标、状态、证据、权限和反馈写清楚，再谈更复杂的循环模式。
Agent 是执行者。
Loop 是让执行者持续改进的方法。
在企业里，决定 Loop 能不能落地的，往往是外面那套工作系统：需求、工单、状态机、审批流、日志、监控、复盘和责任边界。
没有这套东西，Loop 只会把混乱跑得更快。
这也是《架构师》这几篇连续梳理 Harness、AI 工作台、Environment、夜班任务、慢反馈和 Skill 时，最终都会绕回来的地方：任务怎么交接，证据怎么留下，权限怎么收住，反馈怎么进入下一轮。
先把边界说清
• Loop 模式很有用，但它只是执行机制，不是企业工作系统。 • 企业要补的是五类工程对象：目标、状态、证据、权限和反馈。放到传统工程里，就是需求、任务状态、日志与测试、权限审批、复盘和用户信号。 • 企业 AI 准备度更实在的衡量，是组织能不能描述自己的流程、指标、责任人和成本。 • Loop 适合先放进低风险、可验证、可回滚的链路里，比如 CI 失败分流、发版前检查、权限申请初审、文档一致性检查。 • Agent 编码循环越快，人越要管住慢反馈：规格、用户信号、治理和责任边界。
Loop 先落到工单和证据
Rahul 总结的 20 种 Loop 分类，适合当一张地图。它把很多工程师已经熟悉的动作重新放进 AI 系统里：代码评审、测试失败重跑、任务重规划、错误库沉淀、并行方案比较、成本和延迟优化。
更贴近工程地看，Loop 并不神秘。
传统工程里一直有循环。CI 会循环跑测试，任务队列会重试失败 Job，值班系统会告警、处理、复盘，状态机会根据事件推进下一步。
新的地方在于，循环里多了一个会规划、会调用工具、也会犯错的 Agent。
但这里有一个容易被忽略的前提：
Loop 需要一条能交接的任务链路。链路不清，循环就没有可继承的状态。
一次提示可以靠上下文临时凑。
一个 Loop 不行。
它要知道上一轮做了什么，哪些证据已经通过，哪些动作需要人批准，下一轮从哪里继续。
所以 Addy Osmani 在讲 Loop Engineering 时，会把自动化、隔离工作区、Skill、连接器、子 Agent 和状态放在一起看。放到企业里，这些东西对应的是调度、隔离、作业指导书、系统集成、独立复核和状态账本。
靠把提示词写长，解决不了这个问题。
Loop 的工程化，最后会落到状态、证据、权限和交接。
换成企业语言，Loop 模式要先穿过一层“工作契约”。
这张表背后有一个很现实的分水岭。
个人使用 AI，可以先从体验出发。试几轮，不满意就改提示词，结果差一点也只是浪费一点时间。
企业使用 AI，不能只靠这种体感。因为 Loop 一旦接入工单、客户、仓库、知识库、审批流和生产系统，它做的就从“多跑几轮”变成了在组织流程里推进状态。
状态推进以后，责任也会跟着推进。
所以企业讨论 Loop 时，我会先看几个很传统的问题：这次变更是草稿还是正式记录，证据留在哪里，失败以后走重试、降级、回滚还是人工处理。回答不出来，Loop 模式越丰富，系统越难治理。
公司说不清，Agent 就只能猜
Daniel Miessler 的提醒之所以有分量，是因为它落在一个很朴素的问题上：
很多公司抱怨 AI 帮不上忙，其实是自己说不清想让 AI 做什么。
他列了一串问题：公司为客户解决什么问题，目标和指标是什么，正在推进哪些项目，谁负责，成本是多少。
这些问题听起来像管理常识。
但从 Agent 的角度看，它们更像一套可执行元数据。
拆开以后，它们分别对应优化目标、验收指标、任务拆分、责任边界和长期记忆。也就是架构师平时会写进 PRD、ADR、Issue、Runbook、成本模型和复盘记录里的东西。
但真放进企业流程，很多团队并不能稳定回答。目标经常变，指标经常换，任务拆到一半责任又漂移。最后 AI 只能帮忙生成更多文档、更多图表、更多看起来很完整的内容。
这件事放到 Loop 里看，风险更大。
单次调用错了，最多是一段回答错。
Loop 跑偏了，会把偏差一轮轮继承下去。目标不清，系统就围绕模糊目标优化；指标不对，系统就把错误指标做得更漂亮；权限没收住，系统就可能把“候选动作”变成“真实副作用”。
这也是我现在看企业 AI 落地时，比较保守的原因。
一个组织如果还说不清自己的业务链路，急着上 Agent 并不能自动变清楚。
更现实的情况是，AI 会把原来隐藏在会议、表格、邮件、工单里的含糊，批量暴露出来。
这未必是坏事。
前提是团队愿意把这些含糊整理成可执行的工作系统。继续给含糊套一层更漂亮的 AI 外壳，问题不会消失。
五个接口，先落到现有系统
在《想让 Agent 在你睡觉时继续干活？先给它排好夜班》里，我们曾把一条夜班任务压成四类信息：
GOAL.mdSTATE.mdEVIDENCE.mdPERMISSIONS.md放到企业 Loop 里，还要再补一个：
FEEDBACK.md名字可以换，文件也不一定真的叫这个。更贴近日常工程的说法，是把它们落到已有工程对象里。
这张表看起来很土。但真实工程里，很多有复利的东西都很土。
这些接口的价值，是让 Agent 少猜一点，让人少返工一点。
再补一个细节：它们最好别停留在一次性文档里，而要变成可以被系统读写的工作对象。
一个比较稳的接口，至少要做到三件事：版本可查，证据可审，失败可退。
如果做成工程系统，它们可以是 Markdown 文件、Issue 字段、数据库记录，也可以是工作流引擎里的节点属性。
形式不重要。
要紧的是，Loop 不再只活在一次对话里，而是有一份外部账本。
这份账本越清楚，Agent 越容易接手；账本越含糊，人越容易被迫重新查案。
内层越快，外层越要稳
吴恩达最近在 The Batch 里讲三层 Loop，正好补上了企业场景里最容易漏的一层。
第一层是 Agent 编码循环：按规格写代码、跑测试、修复，几分钟一轮。
第二层是开发者反馈循环：人看结果，调整规格、范围和下一步方向。
第三层是外部反馈循环：用户行为、客服工单、销售反馈、A/B Test，把真实信号带回来。
这三层放到企业里看，非常关键。
很多公司最容易升级的是第一层：让 AI 多写、多跑、多改。
这当然有价值。
但如果第二层和第三层跟不上，内层越快，偏差越容易堆。
一个错误规格，Agent 可以实现得很完整。
一个错误指标，系统可以优化得很漂亮。
一个没有真实用户反馈的内部判断，也可以被 AI 总结成一套看似成熟的方法论。
所以企业做 Loop，除了“AI 能不能自动跑”，还得回答几件事：规格谁维护，验收证据谁定义，用户反馈从哪里进入下一轮，哪些判断仍然需要人承担责任。
这些问题听起来没有“自我改进系统”那么新鲜，却决定 Loop 能不能从演示进入真实组织。
自我改进，先放在低风险链路
Loop 这个词很容易让人乐观。
生成、评估、学习、改进，听起来像一个自然上升的系统。
但 Armin Ronacher 提醒了另一个方向：Loop 也会把坏习惯自动化。
今天的模型常见做法是局部防御。看到一个失败，就补一个兜底逻辑；看到一个异常，就再包一层处理；看到一个缺口，就加一点机制。短期看更稳，长期看系统越来越难解释。
如果这些修改发生在短寿命实验、迁移、性能探索、安全扫描里，问题不大。那些场景通常有明确目标，产物可以丢弃或重做，验证也更机械。
但如果 Loop 持续修改的是核心交易链路、长期数据模型、权限系统、合规流程，风险就变了。
它可能把系统维护成一个还能运行、但没人完全理解的东西。
Addy 也讲过类似问题：Loop 越顺，越要加强验证；代码跑得越快，理解债就越容易上涨；如果人只是按下开始按钮，最后可能把判断权也交出去。
我自己的看法会更保守一点。
Loop 适合先放在低风险、可验证、可回滚的链路里。长期资产可以让 Loop 参与，但不能让 Loop 单独承担设计责任。
这更像是对系统复杂度保持敬畏。
买工具之前，先把流程跑顺
Deloitte 2026 年的企业 AI 报告里有几个信号，和这个问题能对上。
它的样本是 2025 年 8 到 9 月的 3,235 名企业领导者。报告里提到，企业 AI 采用率在增长，但实质性重构业务的比例并不高；自主式 AI 的预期影响很强，但自治 Agent 的治理成熟度明显滞后；不少组织认为自己战略上更准备好了，但在基础设施、数据、风险和人才上没那么有底。
这些数字不用拿来吓人。
它们更适合用来把问题看细一点。
报告里有几组数字很值得放在一起看：
• 34% 的受访组织开始用 AI 深度改变业务，比如创造新产品、新服务，或重塑核心流程和商业模式； • 30% 正在围绕 AI 重新设计关键流程； • 37% 仍然停留在比较表层的使用方式，对现有流程几乎没有改动； • 自主式 AI 的使用预期在上升，但只有约五分之一的公司具备成熟的自治 Agent 治理模型； • 42% 的公司认为自己的 AI 采用战略高度准备好了，但在基础设施、数据、风险和人才上，信心明显低一些。
放在一起看，企业 AI 的瓶颈不全在模型能力和工具采购。
更深的瓶颈在任务链路和治理边界。
传统做法是把 AI 加到旧流程上：让它写邮件、总结会议、生成 PPT、查知识库、补代码。
这些都可以做。
但如果流程本身没有被重新整理，AI 很容易只是旧流程的加速器。
Deloitte 还有一个细节很有意思：很多组织调整人才策略时，最常见的做法仍然是教育员工、提升 AI 熟练度；重构角色、工作流和职业路径的比例要低不少。
这也符合很多团队的真实体感。
培训当然有用，但如果培训之后，任务入口、权限边界、验收证据、反馈路径还是老样子，员工只是学会了把 AI 放进旧流程。旧流程没有变清楚，Agent 也只能在旧流程里绕。
能往前走的企业，通常会再深一层：把模糊需求改成可执行规格，把口头经验沉淀成 Runbook 或 Skill，把任务结果变成可审查证据，再把审批、权限、反馈和复盘放进系统边界。
这时 AI 才开始进入组织的执行面，人也会更多回到控制面：判断方向，处理异常，承担责任。
先从发版前检查跑起
如果一个团队今天要试，我不建议先搭“企业级 Agent 平台”。太大，也太容易把问题藏起来。
先挑一条小链路，最好来自传统工程日常：CI 失败分流、发版前检查、权限申请初审、文档链接检查、事故复盘初稿、低风险测试补齐。
判断标准也不用复杂：输入稳定，结果能验，权限低风险，失败能回滚，有人负责验收。
更实在一点，第一版甚至不用新平台。用现有的 Issue、CI、发布清单、只读权限和一个待审文档，就能把这条链路跑起来。先让 Agent 做“检查和整理”，不要一上来就让它“提交和发布”。
比如发版前检查，可以先做一张很小的 Loop 卡：
任务：发版前检查本次变更的文档、配置和关键测试结果，生成待审清单。GOAL：- 检查发布说明、配置项、迁移说明和关键测试结果；- 只生成待审清单，不改生产配置，不发布版本。STATE：- 当前候选版本；- 已检查的 PR、配置文件、迁移脚本；- 仍缺证据的项目。EVIDENCE：- CI 链接、测试日志、Diff、配置变更记录；- 每个风险项对应证据来源。PERMISSIONS：- 可读仓库、CI、发布说明和配置；- 可写待审清单；- 不合并代码，不改生产，不触发发布。FEEDBACK：- 发布负责人确认哪些风险是真问题；- 误报写入排除规则；- 漏检项补进下一次检查清单。这张卡不复杂。
但只要连续跑几次，团队就能看到真实问题：哪些证据稳定，哪些判断过度，人工复核花多久，误报能不能下降。
如果这条链路跑不稳，先别扩大，先改这条 Loop。
如果连续几次都稳，再沉淀成 Skill、Routine、自动化任务或团队流程。
这条路可以分成四级，节奏不用太快：
这四级看起来慢，其实很省时间。
很多失败的企业 AI 项目，问题不一定出在模型第一天就不行，而是团队跳过了前两级，直接把一个还没被人跑顺的流程交给 Agent。结果出了问题以后，才发现目标、证据、权限、责任人都没写清。
我的经验是：如果一条链路人工跑不顺，Agent 只会让问题暴露得更快；如果人工已经跑顺，Agent 才有机会把它变成稳定产能。
这就是从“用 AI”到“让 AI 参与任务链路”的差别。前者更像工具使用，后者更像工程治理。
架构师的老本事，正好用得上
把这件事讲成“提示词工程已死”，多少有些简单。
这种说法传播性强，但对工程判断帮助不大。
提示词还会有用。
变化出现在杠杆点上。
过去我们主要优化一次模型调用：上下文给够没有，指令清楚没有，输出格式稳定没有。
现在要优化一段工作过程：任务从哪里来，谁能改什么，证据怎么留，失败怎么退，反馈怎么进入下一轮。
放到架构师视角里，这更像系统设计问题。
架构师要设计的，已经从 Agent 本身扩展到一套运行环境：它要让 Agent 可以安全工作，可以被人接手，也可以复盘。
这件事并不脱离传统工程。很多老本事反而更重要了。
如果只做工具调用，AI 看起来会很忙；如果这些工程对象没有跟上，它会忙得不可控，最后还很难复盘。
这也是为什么今年这条线会反复写到 Harness、上下文、AI 工作台、Environment、Loop、夜班任务、慢反馈和 Skill。它们看起来像一组热点词，其实是在从不同角度补同一个运行底座。
它们都在回答同一个问题：
当 Agent 从聊天框进入企业流程，哪些目标、状态、证据和权限需要被外置、记录、验证和治理？
最后，先跑一条小链路
20 种 Loop 模式值得收藏。
但我更建议把它当地图，不要当答案。
落到团队里时，先别问“我要不要把 20 种都做一遍”。
先把一条链路问清楚：目标有没有写成验收标准，状态能不能接手，证据能不能复核，权限有没有挡住真实副作用，外部反馈会不会进入下一轮。
如果这些都没有，Loop 再多也只是更复杂的自动化。
如果这些慢慢补齐，哪怕只跑一个很小的 Loop，也已经在改变组织的工作方式。
AI 帮得上忙的公司，未必是最早买工具的公司。
更可能是那些先把任务写清楚、把边界摆清楚、把反馈接回系统的公司。
这样看，企业为 AI 做准备，不能只停在一句“全面拥抱 AI”。
更具体地说，是把自己整理到一个状态：清楚到 AI 能执行，稳到人能接手，透明到结果能被复核。
这件事不花哨。
但它可能比第 21 个 Loop 模式更值钱。
参考资料
• Rahul： 20 Loop Design Patterns Every AI Engineer Should Knowhttps://x.com/sairahul1/status/2072258045460226373• Daniel Miessler： Most Companies Aren't Anywhere Near Ready for AIhttps://danielmiessler.com/blog/most-companies-arent-ready-for-ai• Addy Osmani： Loop Engineeringhttps://addyosmani.com/blog/loop-engineering/• Armin Ronacher： The Coming Loophttps://lucumr.pocoo.org/2026/6/23/the-coming-loop/• Andrew Ng / DeepLearning.AI： Three Key Loops for Building Great Softwarehttps://www.deeplearning.ai/the-batch/three-key-loops-for-building-great-software• Deloitte： The State of AI in the Enterprise 2026https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
往期相关
• 《想让 Agent 在你睡觉时继续干活？先给它排好夜班》 • 《吴恩达三层 Loop：Agent 越快，人越要管慢反馈》 • 《Skill Hell：Agent Skill 怎么写，才不变成旧 Wiki》 • 《Loop 工程实战：从任务循环到可维护闭环》 • 《Anthropic CEO 核心访谈：AI 时代，企业、职场与治理》 如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
架构师 我们都是架构师！
