AX 分享会：面向组织的循环工程

不知从何时起，AI 行业里“XX 工程”的说法越来越常见。去年，XX 还是“提示词”和“上下文”；今年变成了“脚手架”和“循环”，最近又出现了“图”。今天，我想分享自己对略微过气（？）的“循环工程”的思考与经验，以及 Corca 如何通过AX 分享会在组织中运行循环。先说结论：我认为，“为智能体设计循环”和“设计组织的每周重复活动”，要想做得有效，方法惊人地相似。

循环不是一时潮流，而是“真实的”

开发者听到“循环”，大概会想到 for、while 之类的循环语句。如今，这个词开始用于更广泛的语境，例如人在环中（Human-in-the-loop）、人在环上（Human-on-the-loop），以及循环工程。

让这种广义循环真正流行起来的人之一，是 Claude Code 负责人 Boris Cherny。2026 年 6 月 17 日，他在 Meta @Scale 大会与观众的问答中，第一个问题就是关于循环的。

“循环只是下一个炒作周期，还是确有其事？”

Cherny 的回答十分坚定。

“循环是真实的。两年前，我们还在手写源代码；之后转向让智能体写代码；现在则进入了一个智能体向另一个智能体发送提示，再由后者写代码的阶段。正如从源代码到智能体的转变非常巨大，循环也是同样重要而巨大的跃迁。”

如今，主流编码智能体都内置了 goal 功能，让任何人都能轻松运行循环。这不再是执行一次用户提示就结束，而是激活一个“目标”。智能体会自行规划并重复下一步，直到激活目标的完成条件得到满足。

几个月来，Corca 也在非常积极地使用 goal。在一个代码库里，我们会设定大胆目标，偶尔引导自主运行数十小时的智能体；在另一个代码库里，则让它处理反馈周期很短的工作。这些都已成为日常，编码的样貌再次发生了巨大变化。

但循环并非万能

我非常认同 Cherny 所说的循环是一大跃迁，但它当然不是万能的。永不结束的无限循环，正是编码时最想避免的问题之一。我刚开始使用 goal 时，曾给 Codex 一个“关闭所有未解决 Issue”之类的粗糙目标。它运行了 30 个小时，不断消耗 token，我只好强制终止。相反的失望也有很多：睡前设置好一个原以为会长期运行的目标，醒来却只看到“需要某项批准，三次未得到回应，因此已中止”。

也许正是为了避免这些失望、更有效地设计和执行循环，“循环”后面才加上了“工程”。按我的理解，有效循环工程需要满足以下条件：

为智能体提供适当的验证工具和权限，使其能够自行“闭合”循环（例如语法检查器、性能基准、浏览器验证脚手架、独立智能体的强制审查，以及对指定 URL 外部写入的明确授权）。
让智能体能够用机械规则判断实现是否完成（例如执行时间低于阈值、所有测试通过、测试覆盖率达到目标）。
尽量以更少的成本和时间完成实现与验证（例如用聪明但较慢的模型反复讨论设计，由便宜而快速的模型并行实现；能用确定性代码就不用智能体；设定停止条件与预算）。
验证失败时，修复本质而非现象，并进行自我改进（例如不只是重试，而是改进结构模式及其上层模式；把规则写入 AGENTS.md 和文档而不是依赖记忆；也把验证器本身的逻辑和范围纳入改进对象）。
让人容易观察、介入并审查智能体做得如何、结果是否优秀（例如把决策和结果留在文件中；需要决策时停下来询问；用 HTML 和 Mermaid 可视化状态）。

这份清单原本只来自我的经验，但后来发现，Anthropic 的循环入门指南和 Google 的 Addy Osmani 也指出了类似要点。Anthropic 认为，应给智能体能够观察、测量和操作结果的工具；验证越量化，就越容易由智能体自行完成；因此，通过测试数量或分数阈值等确定性标准十分有效。Osmani 在 Loop Engineering 中把循环拆成自动化、工作树、技能、连接器和子智能体五个要素，并在其下放置第六个要素——保留在对话之外的“外部记忆”。

在 Corca，大家也越来越常分享如何满足这些条件、运行更好循环的经验。“设计循环”“闭合循环”这样的表达也越来越常用。把编码中的循环概念提升到智能体层面讨论，已经变得十分自然。

然而，写下这五点后，我感到似曾相识。Corca 已经在更高的组织层面运行着相似的循环。每周四早晨重复举行的AX 分享会，就是它的载体。

组织中也存在循环：AX 分享会的过去与现在

AX 分享会的前身，是去年 11 月开始的“智能体工程每周复盘”。我们与 Moonlight 团队一起，重点分享用 AI 偿还产品技术债的实践。但 Moonlight 毕竟是产品团队，眼前的功能修改和发布更重要，因此活动主要由我和少数以 AX 为本职工作的人推动。代码质量环境和小型实践逐渐出现，但变化速度并不算快。（基于这段经验，我也在 Claude Code Meetup 做过《在遗留代码库中打造让智能体与人都能高效工作的环境》的分享。）

随着全公司的氛围逐步形成，今年 2 至 3 月，活动名称先改为“智能体工程分享会”，又改为“AX 分享会”，雪球开始滚动。它不再由某个人主导，也不再只有特定团队参加。全体成员每周四早晨聚在一起，每次由三个人分享最近与 AI 一起进行的实验及其中的试错。有的人自豪地让新工具在公司内部首次亮相；也有人分享最近读过的书、看过的大会总结，或热门技能与工具的使用体验。不知不觉间，分享会成了扩大 Corca AX 基础、帮助新员工入职的重要活动。

通过 AX 分享会运行组织循环

AX 分享会如今已在 Corca 很好地扎根，但过程中也经历了不少曲折。我们尤其反复思考：“如何让每周重复活动不是形式，而是在个人和组织层面都真正有意义？”因此，早期不断通过讨论和实验来改进活动形式。

经过这些过程，截至 2026 年 8 月稳定下来的形式如下，全程恰好一小时。

自由分享上次复盘中写下的“未来一周要尝试的事”是否真的做了、如何做的，以及其他想说的内容。
本周的三位分享者讲述自己的故事，并留下一项“请试着做这个实验或尝试！”
每个人复盘并写下今天的感受，以及“未来一周要尝试的事”。

表面看第二步是核心，其实它只是引子，围绕它的第一步和第三步才重要。这样，活动才能成为所有人共同参与的“分享会”，而不是某个人主导的“研讨会”，个人和组织也才能持续成长。为此，AX 分享会逐渐发展出在三个时间点发挥作用的文化机制。

分享会结束时：如果复盘里的“要尝试的事”不够小、不够明确，就会受到善意的调侃。（“A，你真的能做到吗？”“B，你的复盘里没有要尝试的事。”“C，我们怎么知道这件事完成了？”）
两次分享会之间：Corca 的智能体同事 Ceal 根据复盘内容发送提醒。第二天，它会整理大家决定要做的事并开一个帖子；对没有标记 :done: 或留言的人，最多发送两次私信，建议“哪怕先做这么小的一步也可以”。Ceal 偶尔故障没发消息时，成员还会开玩笑说：“因为 Ceal 没来催，所以没做。”
下次分享会开始时：我们会直接逐个询问：“做了吗？做了什么？为什么没做？已经几周没做了吧？这周准备怎么办？”这确实带来相当大的压力，有些人会在周四早晨匆忙尝试一点。虽然有些抱歉，但我认为这也是积极的副作用：我们形成了一个小小的共同习惯——周四是尝试新事物的日子。

AX 分享会的形式与机制，和前面提到的“有效循环工程的必要条件”非常相似。

有效循环的必要条件	在智能体循环中	在 AX 分享会中
① 闭合循环的验证工具与权限	语法检查、测试、基准、浏览器脚手架、独立智能体审查	周四早晨逐个问“做了吗？”；Ceal 私信没有回应的人
② 机械式完成判定	所有测试通过、覆盖率不低于 N%	分享会开始与结束时积极而有组织的压力
③ 更少成本与时间	慢模型负责设计、快模型并行实现，并设置停止条件与预算	固定一小时、仅三位分享者、在已有的 Slack 中运行；Ceal 和同事用“哪怕先做这么小的一步”不断缩小行动单元
④ 失败时修复本质	不只重试，而是改进模式，并把规则写入 AGENTS.md 和文档	同一个人持续未完成时，不加倍催促，而是改进调侃、Ceal、开场提问等形式与机制，并在下周应用
⑤ 可观察、可介入、可审查	把决策和结果留在文件中，并可视化状态	把复盘与尝试汇总在大家最常查看的 Notion 和 Slack 帖子里

填写这张表时，我新意识到的是第一点和第四点。不由自己给自己的复盘打分，而由同事在周四早晨询问，这与分离实现智能体和审查智能体的结构相同。当有人连续几周未能尝试时，我们不只是更用力地催促，而是追问“我们的形式遗漏了什么”，再改进机制。这更像是把失败写回规则，而不是逐个打补丁。Ceal 的提醒和分享会开场提问，也正是这样逐项产生的机制。

这或许看起来有些牵强，但我不认为相似性是偶然的。两者都在解决同一个问题：为自主行动的主体提供明确完成标准和反馈。不论主体是人还是智能体，缺少标准和反馈，就可能陷入无尽循环，或不了了之。因此，运行循环的智能体和人都需要适当的帮助。