即刻App年轻人的同好社区
下载
上海这几场 AI 分享，我也非常想听。
下周六，AI Maker Summit 上海站就要来了。
看了讲师们的 PPT，我就觉得这段时间的付出特别值得。全是新鲜的思考和实践。
对了，AI Maker Summit 上海的日程终于确定了。大家可以看看：
aimakersummit.com
这次大会，我们还是做了不少的创新和调整：
1. 内容的受众更多聚焦于工程师、产品经理，所以话题包括 AI Coding、Eval、Agent 设计、Harness Engineering、FDE、AI 产品、AI 投资等等。
2. 所有内容，都有出品人和单独的社区内容评审把关。我们的标准就一条：需要讲新鲜的思考和经验。因为我觉得，泛滥的内容是时代，思考是宝贵的。
3. 所有的讲师，都是直接在参与 Build 的人，都有真知灼见。我特别喜欢和他们交流，总能收获新知。
4. 日程我们做了独立的 Skill，大家可以装到自己的 Agent 中，然后让他来帮你筛选、规划议题。我们团队这次在用户体验方面，下了很多功夫。
5. 有几个专题，分享时长调整为了 20 分钟。我们想看看用户反馈，如果 20 分钟也 ok 的话，那下次北京站，会统一调整为 20 分钟的演讲时长。
6. 线下活动最重要的优点是连接。我们也设计了一些连接的活动，比如会后聚餐等等，让大家能够充分交流，认识新的朋友。
7. 这个大会讲的内容，全部都是实践，都是一线的实践经验。
8. 也许大家可以抽一天时间来，看看这个行业里其他人都在研究什么，思考什么。比如那天我和飞猪的嘉宾交流，才知道人家已经做了很久的 AI Agent 探索了，特别有启发。
9. 线下大会很重要的一个意义，就是让自己偶尔走出熟悉的日常。AI 时代不缺信息，真正稀缺的，是一线经验，以及碰撞之后产生的新想法。
10、欢迎大家报名。目前仍然是优惠价，449元，含全天会议、大会人脉群、讲师面对面交流、会后视频回看与大会纪念伴手礼。下周会恢复原价。
一天时间，四个会场。希望这些内容能给大家带来启发。
大会官网：aimakersummit.com
也许往后某一天，会有人想起来，多少年前在 AI Maker Summit 上海站听到过谁的一个观点，后来激发了他去创业，去做点什么。如果真有那一天，我也与有荣焉。
还是老规矩，日程确定之后，下周折扣期就结束，进入最后一程。
上海见。
下周六，AI Maker Summit 上海站就要来了。
看了讲师们的 PPT，我就觉得这段时间的付出特别值得。全是新鲜的思考和实践。
对了，AI Maker Summit 上海的日程终于确定了。大家可以看看：
aimakersummit.com
这次大会，我们还是做了不少的创新和调整：
1. 内容的受众更多聚焦于工程师、产品经理，所以话题包括 AI Coding、Eval、Agent 设计、Harness Engineering、FDE、AI 产品、AI 投资等等。
2. 所有内容，都有出品人和单独的社区内容评审把关。我们的标准就一条：需要讲新鲜的思考和经验。因为我觉得，泛滥的内容是时代，思考是宝贵的。
3. 所有的讲师，都是直接在参与 Build 的人，都有真知灼见。我特别喜欢和他们交流，总能收获新知。
4. 日程我们做了独立的 Skill，大家可以装到自己的 Agent 中，然后让他来帮你筛选、规划议题。我们团队这次在用户体验方面，下了很多功夫。
5. 有几个专题，分享时长调整为了 20 分钟。我们想看看用户反馈，如果 20 分钟也 ok 的话，那下次北京站，会统一调整为 20 分钟的演讲时长。
6. 线下活动最重要的优点是连接。我们也设计了一些连接的活动，比如会后聚餐等等，让大家能够充分交流，认识新的朋友。
7. 这个大会讲的内容，全部都是实践，都是一线的实践经验。
8. 也许大家可以抽一天时间来，看看这个行业里其他人都在研究什么，思考什么。比如那天我和飞猪的嘉宾交流，才知道人家已经做了很久的 AI Agent 探索了，特别有启发。
9. 线下大会很重要的一个意义，就是让自己偶尔走出熟悉的日常。AI 时代不缺信息，真正稀缺的，是一线经验，以及碰撞之后产生的新想法。
10、欢迎大家报名。目前仍然是优惠价，449元，含全天会议、大会人脉群、讲师面对面交流、会后视频回看与大会纪念伴手礼。下周会恢复原价。
一天时间，四个会场。希望这些内容能给大家带来启发。
大会官网：aimakersummit.com
也许往后某一天，会有人想起来，多少年前在 AI Maker Summit 上海站听到过谁的一个观点，后来激发了他去创业，去做点什么。如果真有那一天，我也与有荣焉。
还是老规矩，日程确定之后，下周折扣期就结束，进入最后一程。
上海见。
2 00
很久没读过这么通透的Agent的文章了。
这周这是怎么了，连续看了两篇我认为是今年最好的AI文章了。
一篇是梁文锋对于接下来 AI 大模型的判断，另外一篇是今天我要写的 EvoMap 张昊阳对于 Agent 的思考。
好久没看到这么通透的、讲 Agent 执行层面的文章了。
evomap.ai
张昊阳和 EvoMap，估计很多人还不太熟悉。我一直在关注他们。
前几个月 Hermes Agent 还有些热度的时候，曾经被人发现，它抄袭了 EvoMap 团队的产品 Evolver。
自进化的逻辑，还有代码实现，Hermes 和 Evolver 都无比接近。
也是那段时间，我在团队内部多次给同事分享过他们公众号的文章。当时最打动我的，是他们对 Agent 的一个判断。
现在的大模型能力越来越强，但每个新启动的 Agent，都是全新的。所以三月份 OpenClaw 大火的时候，大家都说养虾。得从头开始养。
Agent 执行任务的时候，会反复踩坑、不断试错，最后积累一些正确的经验。但这些经验通常只能停留在当前会话，或者当前 Agent 的记忆里，很难传给其他 AI。
举个例子。
一个 Agent 调用某个 API，花了半个小时查文档、改参数，连续失败好几次，最后终于找到正确方法。
对这个 Agent 来说，它确实学会了。但换一个 Agent，遇到同样的问题，往往还得重新踩一遍坑。
当时大家解决这个问题的主要办法，是把经验写成 Skill。Skill 当然很重要，它能把一套流程、工具和方法封装起来，让 Agent 反复调用。
但 Skill 没有解决一个 Agent 在实际工作中刚学到的经验，怎么快速传给其他 Agent。
01 Agent 的经验怎么传递？
EvoMap 的思路是，把 Agent 运行中学到的有效经验，提炼成一种类似基因的东西。当然，基因是加引号的基因。
一个 Agent 找到了解决办法，就把这个办法提炼出来，验证之后上传到网络。以后其他 Agent 遇到类似问题，可以直接继承这段经验，不用再从头摸索。
所以他们最核心的判断是，AI 的经验，也可以成为一种能够流通的资产。
arxiv.org
我当时看到这个想法，觉得非常妙。
那时候大家已经意识到 Skill 是个好东西，但 Skill 更像人提前编写好的一本操作手册。
EvoMap 想从根上彻底解决的是，Agent 每天都在干活，它学到的经验，能不能沉淀下来，再传给更多 Agent？
如果这件事能成立，Agent 就不再只是反复调用一个固定的模型。它在工作中积累的经验，也会慢慢变成整个系统的一部分。
沿着这个思路往前推，自然就会来到多 Agent 协作，也就是 Agent 蜂群。
为什么他们一直用基因这个词？因为生命的进化，本身就依赖基因的传播。
过去我们经常把 AI 比作人。人和今天的 Agent 之间，有两个非常明显的差别。
第一，人能持续学习。遇到一件事，经历一次失败，下次再碰到，通常会处理得更好。
梁文锋也讲过，下一代 AI 一个非常重要的能力，就是自主持续学习。当Agent 能够持续学习跨过自我迭代的奇点，下一代通用智能就会加速
第二，人类的进化不会随着某个个体死亡而中断。
一个人学到的具体知识未必能遗传，但整个物种经过漫长时间形成的生存能力，会通过基因继续传下去。
持续学习得靠模型层面解决。群体经验的传承，得从 Agent 的设计层面入手。
就像《星际争霸》里的虫族。单个个体未必特别强，但每个个体在环境中获得的信息，都可以回传到蜂巢。
整个种群不断调整自己的 DNA，适应新的环境，最后变得越来越强。
如果 Agent 也能形成这种能力，应该会是一个非常重要的突破。这就是 EvoMap 在做的事情。
02 主 Agent 为什么会成为瓶颈？
早上我看到他们又往前跨了一步。这次研究的重点，已经从 Agent 如何共享经验，推进到多个 Agent 如何真正完成协作。
今天大家讲多 Agent，常见做法是设一个主 Agent，再让它调度一批 Sub-Agent。
主 Agent 负责理解目标、拆解任务、分配工作。Sub-Agent 各自执行，最后把结果交回主 Agent，由它汇总。
这个思路看上去很合理，跟现实公司的组织方式也很像。但任务一复杂，主 Agent 很容易成为整个系统的瓶颈。
它得同时掌握完整目标和所有任务的进度，还要读每个 Sub-Agent 返回的材料，判断哪些信息有用，哪些结果可靠，最后重新组织一遍。
Sub-Agent 越多，主 Agent 要处理的上下文就越长。前面已经完成的结果，在一轮轮汇报、压缩和转述中，很容易被遗漏，甚至被重新理解错。
所以 EvoMap 这次其实在探讨两个更底层的问题。
第一，我们现在常见的主 Agent 加 Sub-Agent 这种结构，本质上是不是已经是最优解？
还是说，一项复杂任务有没有可能拆得更彻底，让每个 Agent 只负责一个非常明确、几乎不需要再协调的子任务，最后再用一种更可靠的方式把结果拼接起来？
第二，如果我们不一开始就设计好主 Agent 统筹、Sub-Agent 执行这种固定分工，只是给一群能力相近的 Agent。
它们能不能在执行过程中自己发现各自更擅长的方向，逐渐形成稳定的分工和协作关系？
03 同一个模型，从 26% 到 71%
他们先做了第一个实验。实验一共 563 道题，包括逻辑题、普通数学题、竞赛数学题和物理题。三组实验全部用同一个模型，Claude Haiku 4.5。
第一种方式，让一个 Agent 在同一个上下文里完成全部题目。
第二种方式就是常见的 Sub-Agent 模式。主 Agent 看到完整题目，完成拆解和分配，Sub-Agent 分头解题，再把报告返回给主 Agent，由主 Agent 汇总答案。
第三种方式是 EvoX 蜂群。他们把任务尽可能拆成原子任务，每道题进入一个独立的 Agent。每个 Agent 只处理自己负责的部分，完成以后，
把答案写入提前规定好的位置，最后由程序按照题号直接收集，不再交给另一个大模型重新整理。
最后的差距非常夸张。单 Agent 的正确率是 26.29%。Sub-Agent 模式是 38.54%。EvoX 蜂群达到了 70.69% 到 70.87%。
同一个模型，只是调整了组织和执行方式，正确率就从 26% 提升到接近 71%。
看到这里，大家可能会觉得，蜂群效果更好，是因为它启动了更多 Agent，消耗了更多 Token。
但 Sub-Agent 模式同样启动了很多 Agent，Token 消耗也不低，结果依然远远落后。
所以，蜂群的核心不在于数量。
一群 Agent 同时工作，并不会自然产生群体智能。真正决定结果的，是任务怎么拆，执行过程怎么隔离，最后怎么汇合。
EvoX 首先把任务拆得足够小。每个 Agent 只需要处理一个边界清楚的问题，不用同时照顾几十个目标，也不用频繁切换任务。
这样既方便追踪，也能降低单次任务的复杂度。
其次，每个 Agent 都用独立上下文。一个 Agent 连续处理大量任务时，上下文会越来越长。前面的问题、推理过程和中间答案不断累积，后面的判断也容易受干扰。
EvoX 让每个 Agent 只看到自己负责的那部分内容。它不用记住整个任务发生过什么，只需要完成眼前这件事。
第三个设计，也是我觉得最重要的地方，是他们没有让结果再经过一次大模型汇总。
Agent 负责处理需要推理的问题，程序负责完成确定性的合并。
每个 Agent 都有固定的任务编号和输出位置。程序可以直接检查哪些任务已经完成，哪些任务出现遗漏，再按编号收集答案。
这样，已经正确的结果就不需要再经历一轮转述、概括和取舍。
04 损耗到底在哪里？
他们后来继续检查 Sub-Agent 模式的中间结果，发现了一个特别反直觉的现象。
563 道题里，Sub-Agent 在执行过程中其实已经答对了 373 道。但经过报告传递和主 Agent 的最终汇总，交付出来的正确答案只剩 217 道。
有 166 道题，中间明明已经答对，最后却变成了错误，或者直接消失了。正确答案的保留率只有 55.5%。
这个发现它至少说明，多 Agent 系统的失败并不只发生在执行阶段。
很多任务Sub-Agent 其实做对了，问题出在后续的信息传递和结果汇总里。这个过程很像传话游戏。
Sub-Agent 先完成任务，再整理成报告。主 Agent 读完报告，需要重新理解，再压缩成最终结果。
每多一层自然语言转述，就多一次信息损失的机会。原始答案可能没被提取出来，格式可能发生变化，前面的正确内容也可能被后面的错误覆盖。
EvoX 蜂群的思路非常朴素。既然题目已经答完，就别再让另一个大模型去读一遍、理解一遍。
让 Agent 专心解题，答案由一段写死的程序按编号收集拼接，不做任何二次加工。
有点意思这个思路。
因为我们今天设计 Agent 工作流的时候，很容易陷入一个误区，什么事情都想交给大模型。
让大模型拆解，让大模型执行，让大模型汇报，再让另一个大模型汇总。但有些环节，传统程序要可靠得多。
比如任务有没有遗漏，结果是否重复，输出格式是否正确，某个任务是否超时，这些事情都有明确规则，完全可以交给程序处理。
大模型更适合处理模糊和不确定的问题。代码的确定性和稳定性则会高很多。
一个蜂群需要足够自由，每个 Agent 可以发挥自己的能力。同时也需要一套稳定的底层协议，保证所有局部结果最后能拼成完整的交付。
理解到这，我估计很多同学跟我有一样的疑惑，会怀疑前面的 case 是不是过于简单。
前面的题目，人可以提前把分工排好，谁做哪道题，答案放在哪，都是清楚的。但很多复杂任务，分工本身就没法提前定死。
比如开发一个产品，前端任务可能依赖接口设计，接口设计又依赖数据结构。
执行过程中还可能冒出新问题，有些任务需要返工，有些任务会重复，也有些任务突然失去意义。
这种情况下，人都很难提前把全部任务和组织关系写死。
05 Agent 的自组织
所以，他们继续做了第二个实验。这次研究的问题是：Agent 能不能在工作过程中逐渐形成自己的专长，再根据这些专长选择合作伙伴，产生比人类更高效的组织形式？
实验最开始放入 24 个配置完全相同的 Agent。这些 Agent 没有提前设置角色。
它们先完成多轮任务。每处理一道题，Agent 都会总结这类题目的经验，并把经验记录到自己的 Memory 里。这些经验在实验中被称为 Gene。
有的 Agent 选的物理题比较多，慢慢积累了更多物理经验。
有的 Agent 经常解决数学题，逐渐形成了数学方向的能力。
经过八轮任务之后，原本完全相同的 Agent，开始拥有不同的经历、专业侧重和历史正确率。
也就是说，它们的身份不是人提前指定的，而是在一轮轮选择和执行中慢慢形成的。
接下来，研究团队让这些 Agent 自主选择新的伙伴。
当 Agent 只能看到彼此之间的连接关系时，它更喜欢选择朋友的朋友。最后形成的网络里，保留了很多熟人小圈子。
当 Agent 可以看到候选者的专业侧重和历史正确率时，它的选择马上变了。它开始连接正确率更高的 Agent，也会寻找专业能力更适合自己的人。
同一个 Agent，只因为能看到的信息不同，就选择了完全不同的合作对象。大量个体选择累积之后，整个 Agent 网络的形态也跟着改变。
只展示社交关系时，Agent 更容易在原来的圈子里继续连接。
展示能力和表现以后，一些高正确率的 Agent 开始成为网络里的枢纽，其他 Agent 会跨过原来的关系，主动连接更适合完成任务的人。
同一群 Agent，最后长出了两种不同的组织形态。
不过，这个实验目前只验证了自组织最早期的一个动作，也就是选择伙伴。这些连接还没有真正承担任务转交和协作。
Agent 还没有完整实现自主拆解、认领任务、处理冲突和重新分配工作。所以现在说它们已经形成了完整的 Agent 社会，还太早。
但这个实验已经透露出一个很有意思的信号：
Agent 的组织方式，会受到可见信息的影响。只提供关系信息，它们就容易找熟人。
提供能力和历史表现，它们就会找更合适的合作对象。
以后如果再加入成本、信用、响应速度和历史合作记录，可能还会形成更复杂的关系。
所以，Agent 的自组织并不会凭空发生。系统向它们展示什么信息，奖励什么行为，它们就更容易形成什么样的组织。
06 写在最后
写到这里，这篇文章也就结束了。大周六的，从早上 7:30 写到 11:45，几乎一气呵成。
毫不夸张的说，我觉得这是今年我读过的 Agent 落地方面最重要的一篇文章了。
所有做 Agent 研究的朋友都可以去看一看 EvoMap 这家公司，他们现在的很多实验还处于早期阶段，一些结论也需要继续验证。
但他们提出问题的方式，以及解决问题时对工程细节的重视，确实让我眼前一亮。
现在的大模型已经足够聪明，单个 Agent 也能完成越来越长的任务。
但只要任务继续变复杂，靠一个主 Agent 管理所有事情，很快就会碰到上下文、协调和结果损耗的问题。
接下来真正关键的突破，可能会同时发生在两个方向。
一个方向，是让 Agent 在工作中积累的经验能够保存、验证和传播。另一个方向，是让越来越多的 Agent 在稳定的规则下完成分工，并根据任务和能力调整自己的协作关系。
这两件事一旦逐渐成熟，Agent 就会发生一次彻底的变化。我不知道这一天具体什么时候到来。
但读完这篇文章，我第一次觉得，这条路已经隐约出现了。
这周这是怎么了，连续看了两篇我认为是今年最好的AI文章了。
一篇是梁文锋对于接下来 AI 大模型的判断，另外一篇是今天我要写的 EvoMap 张昊阳对于 Agent 的思考。
好久没看到这么通透的、讲 Agent 执行层面的文章了。
evomap.ai
张昊阳和 EvoMap，估计很多人还不太熟悉。我一直在关注他们。
前几个月 Hermes Agent 还有些热度的时候，曾经被人发现，它抄袭了 EvoMap 团队的产品 Evolver。
自进化的逻辑，还有代码实现，Hermes 和 Evolver 都无比接近。
也是那段时间，我在团队内部多次给同事分享过他们公众号的文章。当时最打动我的，是他们对 Agent 的一个判断。
现在的大模型能力越来越强，但每个新启动的 Agent，都是全新的。所以三月份 OpenClaw 大火的时候，大家都说养虾。得从头开始养。
Agent 执行任务的时候，会反复踩坑、不断试错，最后积累一些正确的经验。但这些经验通常只能停留在当前会话，或者当前 Agent 的记忆里，很难传给其他 AI。
举个例子。
一个 Agent 调用某个 API，花了半个小时查文档、改参数，连续失败好几次，最后终于找到正确方法。
对这个 Agent 来说，它确实学会了。但换一个 Agent，遇到同样的问题，往往还得重新踩一遍坑。
当时大家解决这个问题的主要办法，是把经验写成 Skill。Skill 当然很重要，它能把一套流程、工具和方法封装起来，让 Agent 反复调用。
但 Skill 没有解决一个 Agent 在实际工作中刚学到的经验，怎么快速传给其他 Agent。
01 Agent 的经验怎么传递？
EvoMap 的思路是，把 Agent 运行中学到的有效经验，提炼成一种类似基因的东西。当然，基因是加引号的基因。
一个 Agent 找到了解决办法，就把这个办法提炼出来，验证之后上传到网络。以后其他 Agent 遇到类似问题，可以直接继承这段经验，不用再从头摸索。
所以他们最核心的判断是，AI 的经验，也可以成为一种能够流通的资产。
arxiv.org
我当时看到这个想法，觉得非常妙。
那时候大家已经意识到 Skill 是个好东西，但 Skill 更像人提前编写好的一本操作手册。
EvoMap 想从根上彻底解决的是，Agent 每天都在干活，它学到的经验，能不能沉淀下来，再传给更多 Agent？
如果这件事能成立，Agent 就不再只是反复调用一个固定的模型。它在工作中积累的经验，也会慢慢变成整个系统的一部分。
沿着这个思路往前推，自然就会来到多 Agent 协作，也就是 Agent 蜂群。
为什么他们一直用基因这个词？因为生命的进化，本身就依赖基因的传播。
过去我们经常把 AI 比作人。人和今天的 Agent 之间，有两个非常明显的差别。
第一，人能持续学习。遇到一件事，经历一次失败，下次再碰到，通常会处理得更好。
梁文锋也讲过，下一代 AI 一个非常重要的能力，就是自主持续学习。当Agent 能够持续学习跨过自我迭代的奇点，下一代通用智能就会加速
第二，人类的进化不会随着某个个体死亡而中断。
一个人学到的具体知识未必能遗传，但整个物种经过漫长时间形成的生存能力，会通过基因继续传下去。
持续学习得靠模型层面解决。群体经验的传承，得从 Agent 的设计层面入手。
就像《星际争霸》里的虫族。单个个体未必特别强，但每个个体在环境中获得的信息，都可以回传到蜂巢。
整个种群不断调整自己的 DNA，适应新的环境，最后变得越来越强。
如果 Agent 也能形成这种能力，应该会是一个非常重要的突破。这就是 EvoMap 在做的事情。
02 主 Agent 为什么会成为瓶颈？
早上我看到他们又往前跨了一步。这次研究的重点，已经从 Agent 如何共享经验，推进到多个 Agent 如何真正完成协作。
今天大家讲多 Agent，常见做法是设一个主 Agent，再让它调度一批 Sub-Agent。
主 Agent 负责理解目标、拆解任务、分配工作。Sub-Agent 各自执行，最后把结果交回主 Agent，由它汇总。
这个思路看上去很合理，跟现实公司的组织方式也很像。但任务一复杂，主 Agent 很容易成为整个系统的瓶颈。
它得同时掌握完整目标和所有任务的进度，还要读每个 Sub-Agent 返回的材料，判断哪些信息有用，哪些结果可靠，最后重新组织一遍。
Sub-Agent 越多，主 Agent 要处理的上下文就越长。前面已经完成的结果，在一轮轮汇报、压缩和转述中，很容易被遗漏，甚至被重新理解错。
所以 EvoMap 这次其实在探讨两个更底层的问题。
第一，我们现在常见的主 Agent 加 Sub-Agent 这种结构，本质上是不是已经是最优解？
还是说，一项复杂任务有没有可能拆得更彻底，让每个 Agent 只负责一个非常明确、几乎不需要再协调的子任务，最后再用一种更可靠的方式把结果拼接起来？
第二，如果我们不一开始就设计好主 Agent 统筹、Sub-Agent 执行这种固定分工，只是给一群能力相近的 Agent。
它们能不能在执行过程中自己发现各自更擅长的方向，逐渐形成稳定的分工和协作关系？
03 同一个模型，从 26% 到 71%
他们先做了第一个实验。实验一共 563 道题，包括逻辑题、普通数学题、竞赛数学题和物理题。三组实验全部用同一个模型，Claude Haiku 4.5。
第一种方式，让一个 Agent 在同一个上下文里完成全部题目。
第二种方式就是常见的 Sub-Agent 模式。主 Agent 看到完整题目，完成拆解和分配，Sub-Agent 分头解题，再把报告返回给主 Agent，由主 Agent 汇总答案。
第三种方式是 EvoX 蜂群。他们把任务尽可能拆成原子任务，每道题进入一个独立的 Agent。每个 Agent 只处理自己负责的部分，完成以后，
把答案写入提前规定好的位置，最后由程序按照题号直接收集，不再交给另一个大模型重新整理。
最后的差距非常夸张。单 Agent 的正确率是 26.29%。Sub-Agent 模式是 38.54%。EvoX 蜂群达到了 70.69% 到 70.87%。
同一个模型，只是调整了组织和执行方式，正确率就从 26% 提升到接近 71%。
看到这里，大家可能会觉得，蜂群效果更好，是因为它启动了更多 Agent，消耗了更多 Token。
但 Sub-Agent 模式同样启动了很多 Agent，Token 消耗也不低，结果依然远远落后。
所以，蜂群的核心不在于数量。
一群 Agent 同时工作，并不会自然产生群体智能。真正决定结果的，是任务怎么拆，执行过程怎么隔离，最后怎么汇合。
EvoX 首先把任务拆得足够小。每个 Agent 只需要处理一个边界清楚的问题，不用同时照顾几十个目标，也不用频繁切换任务。
这样既方便追踪，也能降低单次任务的复杂度。
其次，每个 Agent 都用独立上下文。一个 Agent 连续处理大量任务时，上下文会越来越长。前面的问题、推理过程和中间答案不断累积，后面的判断也容易受干扰。
EvoX 让每个 Agent 只看到自己负责的那部分内容。它不用记住整个任务发生过什么，只需要完成眼前这件事。
第三个设计，也是我觉得最重要的地方，是他们没有让结果再经过一次大模型汇总。
Agent 负责处理需要推理的问题，程序负责完成确定性的合并。
每个 Agent 都有固定的任务编号和输出位置。程序可以直接检查哪些任务已经完成，哪些任务出现遗漏，再按编号收集答案。
这样，已经正确的结果就不需要再经历一轮转述、概括和取舍。
04 损耗到底在哪里？
他们后来继续检查 Sub-Agent 模式的中间结果，发现了一个特别反直觉的现象。
563 道题里，Sub-Agent 在执行过程中其实已经答对了 373 道。但经过报告传递和主 Agent 的最终汇总，交付出来的正确答案只剩 217 道。
有 166 道题，中间明明已经答对，最后却变成了错误，或者直接消失了。正确答案的保留率只有 55.5%。
这个发现它至少说明，多 Agent 系统的失败并不只发生在执行阶段。
很多任务Sub-Agent 其实做对了，问题出在后续的信息传递和结果汇总里。这个过程很像传话游戏。
Sub-Agent 先完成任务，再整理成报告。主 Agent 读完报告，需要重新理解，再压缩成最终结果。
每多一层自然语言转述，就多一次信息损失的机会。原始答案可能没被提取出来，格式可能发生变化，前面的正确内容也可能被后面的错误覆盖。
EvoX 蜂群的思路非常朴素。既然题目已经答完，就别再让另一个大模型去读一遍、理解一遍。
让 Agent 专心解题，答案由一段写死的程序按编号收集拼接，不做任何二次加工。
有点意思这个思路。
因为我们今天设计 Agent 工作流的时候，很容易陷入一个误区，什么事情都想交给大模型。
让大模型拆解，让大模型执行，让大模型汇报，再让另一个大模型汇总。但有些环节，传统程序要可靠得多。
比如任务有没有遗漏，结果是否重复，输出格式是否正确，某个任务是否超时，这些事情都有明确规则，完全可以交给程序处理。
大模型更适合处理模糊和不确定的问题。代码的确定性和稳定性则会高很多。
一个蜂群需要足够自由，每个 Agent 可以发挥自己的能力。同时也需要一套稳定的底层协议，保证所有局部结果最后能拼成完整的交付。
理解到这，我估计很多同学跟我有一样的疑惑，会怀疑前面的 case 是不是过于简单。
前面的题目，人可以提前把分工排好，谁做哪道题，答案放在哪，都是清楚的。但很多复杂任务，分工本身就没法提前定死。
比如开发一个产品，前端任务可能依赖接口设计，接口设计又依赖数据结构。
执行过程中还可能冒出新问题，有些任务需要返工，有些任务会重复，也有些任务突然失去意义。
这种情况下，人都很难提前把全部任务和组织关系写死。
05 Agent 的自组织
所以，他们继续做了第二个实验。这次研究的问题是：Agent 能不能在工作过程中逐渐形成自己的专长，再根据这些专长选择合作伙伴，产生比人类更高效的组织形式？
实验最开始放入 24 个配置完全相同的 Agent。这些 Agent 没有提前设置角色。
它们先完成多轮任务。每处理一道题，Agent 都会总结这类题目的经验，并把经验记录到自己的 Memory 里。这些经验在实验中被称为 Gene。
有的 Agent 选的物理题比较多，慢慢积累了更多物理经验。
有的 Agent 经常解决数学题，逐渐形成了数学方向的能力。
经过八轮任务之后，原本完全相同的 Agent，开始拥有不同的经历、专业侧重和历史正确率。
也就是说，它们的身份不是人提前指定的，而是在一轮轮选择和执行中慢慢形成的。
接下来，研究团队让这些 Agent 自主选择新的伙伴。
当 Agent 只能看到彼此之间的连接关系时，它更喜欢选择朋友的朋友。最后形成的网络里，保留了很多熟人小圈子。
当 Agent 可以看到候选者的专业侧重和历史正确率时，它的选择马上变了。它开始连接正确率更高的 Agent，也会寻找专业能力更适合自己的人。
同一个 Agent，只因为能看到的信息不同，就选择了完全不同的合作对象。大量个体选择累积之后，整个 Agent 网络的形态也跟着改变。
只展示社交关系时，Agent 更容易在原来的圈子里继续连接。
展示能力和表现以后，一些高正确率的 Agent 开始成为网络里的枢纽，其他 Agent 会跨过原来的关系，主动连接更适合完成任务的人。
同一群 Agent，最后长出了两种不同的组织形态。
不过，这个实验目前只验证了自组织最早期的一个动作，也就是选择伙伴。这些连接还没有真正承担任务转交和协作。
Agent 还没有完整实现自主拆解、认领任务、处理冲突和重新分配工作。所以现在说它们已经形成了完整的 Agent 社会，还太早。
但这个实验已经透露出一个很有意思的信号：
Agent 的组织方式，会受到可见信息的影响。只提供关系信息，它们就容易找熟人。
提供能力和历史表现，它们就会找更合适的合作对象。
以后如果再加入成本、信用、响应速度和历史合作记录，可能还会形成更复杂的关系。
所以，Agent 的自组织并不会凭空发生。系统向它们展示什么信息，奖励什么行为，它们就更容易形成什么样的组织。
06 写在最后
写到这里，这篇文章也就结束了。大周六的，从早上 7:30 写到 11:45，几乎一气呵成。
毫不夸张的说，我觉得这是今年我读过的 Agent 落地方面最重要的一篇文章了。
所有做 Agent 研究的朋友都可以去看一看 EvoMap 这家公司，他们现在的很多实验还处于早期阶段，一些结论也需要继续验证。
但他们提出问题的方式，以及解决问题时对工程细节的重视，确实让我眼前一亮。
现在的大模型已经足够聪明，单个 Agent 也能完成越来越长的任务。
但只要任务继续变复杂，靠一个主 Agent 管理所有事情，很快就会碰到上下文、协调和结果损耗的问题。
接下来真正关键的突破，可能会同时发生在两个方向。
一个方向，是让 Agent 在工作中积累的经验能够保存、验证和传播。另一个方向，是让越来越多的 Agent 在稳定的规则下完成分工，并根据任务和能力调整自己的协作关系。
这两件事一旦逐渐成熟，Agent 就会发生一次彻底的变化。我不知道这一天具体什么时候到来。
但读完这篇文章，我第一次觉得，这条路已经隐约出现了。
0 00
Anthropic 总算把 Loop 是什么说清楚了。
最近一段时间，越来越多人开始讨论一个词：Loop。
尤其是在 Coding Agent 圈子里，大家经常说，接下来真正重要的已经不只是怎么写 Prompt，而是怎么设计 Loop。
刚开始看到这个说法，我也觉得有点抽象。Agent 本身不就会反复思考、调用工具、修改代码吗？为什么还要专门设计一个 Loop？
周末两天看完 Claude Code 团队写的一篇文章，我才发现，这件事其实没有那么玄乎。
x.com
他们对 Loop 的定义很简单：
让 Agent 重复执行一段工作，直到满足某个停止条件。
比如让 Agent 修改代码、运行测试、检查报错。如果测试没通过，它就继续修改。全部通过之后，任务结束。
这就是一个最简单的 Loop。
再比如，每隔一个小时检查一次 GitHub 上有没有新的 Issue。有的话就分类、分析原因、尝试修复，没有的话就等待下一次检查。
这也是一个 Loop。
它和我们平时说的多试几次、定期跑个脚本很像。
区别在于，传统脚本只能执行提前写好的固定步骤，Agent 可以根据每一轮的结果，重新判断下一步应该做什么。
Claude Code 团队按照 Loop 如何触发、如何停止，以及人交出了哪一部分控制权，把它分成了四种类型：
对话式 Loop、目标式 Loop、定时式 Loop，以及流水线 Loop。
这四种 Loop 并不是完全独立的。它们更像一条逐渐递进的路线：一开始由人推动每一轮，后来把验收条件、触发时机，甚至整条工作流逐步交给 Agent。
第一种：对话式 Loop
我们平时使用 Agent，其实已经在跑这种 Loop。
很多人会把 Loop 想成一套很复杂的自动化系统。其实我们每天和 Codex、Claude Code 对话的时候，就已经在跑一种最简单的 Loop。
比如我让 Codex 帮我修一个前端 Bug。
它会先读一下代码，找到可能的问题，修改文件，然后运行测试。它觉得任务完成之后，把结果返回给我。
接下来，我打开网页看一眼，发现按钮虽然能点，但手机上的样式错位了。于是我再补一句：移动端的布局还有问题，继续修改。
Agent 再执行一遍。
在这个过程中，Agent 跑完一圈，我检查一次，然后决定要不要继续。我们两个人在接力跑圈。
Claude Code 团队把它叫作 Turn-based Loop，也就是由一轮轮对话推动的循环。
这种方式非常适合探索性的工作。比如第一次分析一个陌生项目、尝试实现一个新功能、写一篇文章，或者研究一个还没有明确答案的问题。
因为任务刚开始的时候，我们自己可能也不知道最终应该做成什么样。Agent 每完成一步，我们看一下结果，再决定下一步往哪里走。
这时候，人依然是 Loop 里很重要的一环。
问题在于，我们经常重复做相同的检查。
每次 Agent 修改完前端，我都要打开页面，分别检查电脑和手机的显示效果；点击几个按钮；看看浏览器控制台有没有报错；再跑一遍测试。
既然检查流程每次都差不多，就可以把它写成一个 Skill，或者一份固定的验收说明。
以后 Agent 完成修改之后，先按照这份说明自己检查一遍。发现问题就继续改，全部通过以后再来找我。
这样一来，原本需要我亲自完成的一部分 Loop，就被固化进了系统。
这个思路不只适用于代码。写文章也一样。
可以把自己的检查标准写下来：有没有事实错误，开头是不是太慢，有没有重复表达，案例是否真实，是否出现了自己不喜欢的句式。
做数据分析时，也可以要求 Agent 检查数据口径、异常值、时间范围和计算结果。
Skill 的价值，不只是教 Agent 怎么干活，它还可以把我们平时怎么验收工作固化下来。
第二种：目标式 Loop
复杂任务，需要先告诉 Agent 什么叫完成。普通对话式 Loop 有一个很明显的问题：Agent 经常不知道什么时候应该停止。
你让它优化一下这个页面，它改了字体、调整了间距，可能就认为自己已经完成了。
但你心里的优化，可能是让 Lighthouse 分数超过 90，让首屏加载时间低于两秒，或者让所有移动端测试全部通过。
“优化一下”很模糊，“Lighthouse 分数达到 90”就清楚多了。这类任务更适合 Goal-based Loop，也就是目标驱动的循环。
在 Claude Code 里，Anthropic 提供了 /goal。不过这套思路并不属于某个产品。无论使用 Codex、Claude Code，还是自己搭的 Agent，核心都一样：
提前定义一个可以验证的完成条件，让 Agent 没达到目标之前继续工作。
比如：把首页的 Lighthouse 性能分数提高到 90 以上，最多尝试 5 轮。
Agent 每完成一轮修改，都要重新测试。如果分数只有 83，就继续分析瓶颈；达到 91，Loop 才结束。
这里有两个条件。
一个是成功条件：分数达到 90。另一个是兜底条件：最多尝试 5 轮。
只有成功条件，Agent 可能为了一个无法实现的目标不停消耗 Token。只有轮数限制，它又可能在任务还没有真正完成时提前结束。
目标驱动的 Loop，适合所有结果可以明确验收的任务。
代码测试全部通过、页面没有控制台报错、表格中没有空值、迁移的数据量与原系统一致、研究报告覆盖指定的十家公司，都可以成为停止条件。
它和普通 Prompt 最大的差别，在于我们不再只告诉 Agent 做一个动作，还会告诉它做到什么程度。
过去我们经常写：帮我检查一下这个产品。换成 Loop 的思路之后，可能会变成：
分别在电脑端和移动端测试注册、登录、支付和退款流程。每个流程至少覆盖正常路径和一个异常路径。
发现问题后尝试复现，并记录操作步骤、截图和控制台日志。所有测试完成，且每个问题都有明确记录后结束。
Agent 能不能持续工作，很多时候并不取决于模型够不够聪明，关键在于我们有没有把“完成”说清楚。
第三种：定时式 Loop
有些任务一次做完就结束了，还有一些任务会按照固定节奏反复出现。
比如每天早上汇总昨天的行业新闻，每半个小时查看一次 CI，每周整理一次销售数据，或者持续关注客户反馈。
这时，Loop 需要解决另一个问题：什么时候开始下一轮？
最简单的方式是按照时间触发。
在 Claude Code 中，可以用 /loop 每隔一段时间重复执行同一个任务，也可以通过 /schedule 把它放到云端长期运行。
其他 Agent 产品里，可能叫定时任务、自动化或者 Routine，名字不同，逻辑差不多。
假设一个 PR 正在等待审核，可以让 Agent 每隔十分钟检查一次：
如果收到新的 Review 评论，就读取评论、修改代码并重新提交；如果 CI 失败，就查看日志并尝试修复；如果 PR 已经合并，Loop 自动结束。
这种方式特别适合需要和外部系统打交道的工作。因为外部状态一直在变化，Agent 必须隔一段时间看一眼，才能知道要不要行动。
不过，定时检查也很容易浪费 Token。如果一个频道一天只有几条新消息，却让 Agent 每分钟检查一次，大部分运行都没什么实际价值。
所以，能用事件触发的地方，最好用事件触发。
收到新邮件时启动、出现新的 Issue 时启动、CI 失败时启动，通常比不断轮询更省 Token。
暂时接不上事件系统，再考虑定时检查。检查频率也要根据实际变化速度来设置。
第四种：流水线 Loop
再往前一步，就是 Proactive Loop，也就是流水线 Loop。
这时候，Loop 不再只负责重复一个动作，而是变成一条长期运行的工作流水线。
比如，公司有一个产品反馈频道。过去每天都需要有人进去查看消息，把反馈分成 Bug、功能建议和使用问题，再分别转给产品、研发或客服。
如果使用 Proactive Loop，可以把整套流程连起来：
系统收到新反馈后，Agent 自动读取内容，判断类型，检查是否存在重复问题。
如果是 Bug，就尝试复现，收集日志，创建 Issue；如果能够明确定位，就让 Coding Agent 创建分支并尝试修复。
另一个 Agent 负责 Review；确认无误后，再给用户回复处理进展。人不需要在每一个步骤中点一下继续。
只有遇到高风险操作、信息不足或者多个方案难以取舍时，Agent 才把任务交回来。
这类 Loop 的特点，是输入会源源不断地出现，但处理流程相对稳定。Bug 分拣、数据迁移、发票处理、客户反馈、内容审核，都很适合这种模式。
Loop 的演进过程，本质上是人逐渐退出执行链路的过程。但退出不等于完全不管。
人的工作会往前移动到：设计流程、定义边界、写验收标准、处理例外情况。
Loop 怎么保证质量
Loop 最危险的地方，是它会放大系统原有的问题。
一次调用做错了，可能只产生一个错误结果。一个长期运行的 Loop 如果缺少检查，可能连续制造几百个错误。
所以，Loop 只是一个不断重复执行的壳。真正决定质量的，是周围的环境。
做 Coding Loop 时，代码库本身要尽量干净，目录、命名和测试方式要保持一致。Agent 很擅长模仿已有代码。
项目里到处都是临时方案，它也会继续生成临时方案。
文档也要放在 Agent 容易找到的位置。使用什么框架、接口如何调用、哪些目录不能修改、发布流程是什么，都应该写清楚。
更重要的是，Agent 必须有办法看到自己的结果。
比如修改网页之后，要能打开浏览器实际操作一遍。
写完代码要能跑测试，生成数据要能用脚本核对。做 Research 也一样，最后要能回到原始来源逐项检查。
很多任务失败，并非 Agent 不会做，而是它做完以后看不到结果，只能凭感觉宣布完成。
对于重要任务，还可以引入第二个 Agent 做 Review。
负责写代码的 Agent 容易顺着自己的思路继续往下走。换一个拥有全新上下文的 Agent 检查，更容易发现遗漏。写作、研究和数据分析同样可以这样做。
一个 Agent 负责生产，另一个 Agent 负责挑错，最后再由规则或人做决定。
还有一个很重要的习惯：某次 Loop 出错以后，不要只修这一次的结果。
需要继续追问：为什么系统没有提前发现？能不能增加一条测试？能不能把判断标准写进 Skill？能不能增加一个必须经过的 Review 环节？
这样，每次失败都能让下一轮 Loop 更稳定。
设计 Loop，也是在设计成本
Agent 可以无限尝试，钱不可以无限烧。
Loop 最容易出现的情况，就是任务目标模糊、停止条件缺失，几个 Agent 互相讨论了很久，最后没有产生多少有效结果。
控制成本，第一步仍然是缩小任务。
能一次调用解决的问题，没有必要启动三个 Agent。能够用脚本完成的固定动作，也不要每次都让模型重新推理。
比如把数据转换成固定格式，写一个脚本通常更快、更稳定。Agent 只负责判断什么时候运行脚本、参数应该填什么，以及运行失败以后如何处理。
模型也可以分层使用。
读取消息、提取字段这类固定动作，可以交给更快更便宜的模型。遇到架构层面的判断或者比较复杂的排错，再用能力更强的模型来处理。
对于批量任务，先拿十条数据试跑一下。确认效果和成本之后，再扩大到一千条。不要一上来就让动态工作流启动几百个 Agent。
一个可靠的 Loop，通常都带着明确的边界：最多运行多少轮、最多处理多少条、消耗达到多少时暂停、哪些操作必须经过人确认。
没有边界的自动化，很容易从生产力工具变成 Token 粉碎机。
怎么开始第一个 Loop？
我觉得不用一开始就搭一套庞大的多 Agent 系统。
先观察自己每天的工作，找到那个反复出现、结构比较稳定，又总需要自己盯着的环节。
可能是每次发布文章之前检查错别字和事实，可能是每天整理客户反馈，也可能是代码修改完成后反复测试几个页面。
然后把这件事拆成几个问题：
什么情况会触发它？Agent 每一轮需要完成什么？它如何看到并验证结果？什么条件代表任务完成？最多允许尝试多少次？什么情况必须停下来找人接管？
甚至可以直接套用一个很简单的模板：
当某件事发生时，Agent 执行某项工作。完成后使用某种方法检查结果。
如果没有通过，就根据反馈继续修改，最多重试若干次。满足某个条件后结束。遇到某类风险或不确定情况时，交给人处理。
先跑起来，再观察它容易卡在哪里，又会在哪些地方冲得太快，然后不断补充工具、验收条件和边界。
过去，我们使用 Agent，更多是在研究一句 Prompt 应该怎么写。到了 Loop 这一步，我们开始设计一整段工作该怎么持续运行。
Prompt 决定 Agent 这一轮做什么。Loop 决定它如何根据结果继续工作，什么时候再次启动，又在什么地方真正停下来。
推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。现在 6 折售票中。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
aimakersummit.com
最近一段时间，越来越多人开始讨论一个词：Loop。
尤其是在 Coding Agent 圈子里，大家经常说，接下来真正重要的已经不只是怎么写 Prompt，而是怎么设计 Loop。
刚开始看到这个说法，我也觉得有点抽象。Agent 本身不就会反复思考、调用工具、修改代码吗？为什么还要专门设计一个 Loop？
周末两天看完 Claude Code 团队写的一篇文章，我才发现，这件事其实没有那么玄乎。
x.com
他们对 Loop 的定义很简单：
让 Agent 重复执行一段工作，直到满足某个停止条件。
比如让 Agent 修改代码、运行测试、检查报错。如果测试没通过，它就继续修改。全部通过之后，任务结束。
这就是一个最简单的 Loop。
再比如，每隔一个小时检查一次 GitHub 上有没有新的 Issue。有的话就分类、分析原因、尝试修复，没有的话就等待下一次检查。
这也是一个 Loop。
它和我们平时说的多试几次、定期跑个脚本很像。
区别在于，传统脚本只能执行提前写好的固定步骤，Agent 可以根据每一轮的结果，重新判断下一步应该做什么。
Claude Code 团队按照 Loop 如何触发、如何停止，以及人交出了哪一部分控制权，把它分成了四种类型：
对话式 Loop、目标式 Loop、定时式 Loop，以及流水线 Loop。
这四种 Loop 并不是完全独立的。它们更像一条逐渐递进的路线：一开始由人推动每一轮，后来把验收条件、触发时机，甚至整条工作流逐步交给 Agent。
第一种：对话式 Loop
我们平时使用 Agent，其实已经在跑这种 Loop。
很多人会把 Loop 想成一套很复杂的自动化系统。其实我们每天和 Codex、Claude Code 对话的时候，就已经在跑一种最简单的 Loop。
比如我让 Codex 帮我修一个前端 Bug。
它会先读一下代码，找到可能的问题，修改文件，然后运行测试。它觉得任务完成之后，把结果返回给我。
接下来，我打开网页看一眼，发现按钮虽然能点，但手机上的样式错位了。于是我再补一句：移动端的布局还有问题，继续修改。
Agent 再执行一遍。
在这个过程中，Agent 跑完一圈，我检查一次，然后决定要不要继续。我们两个人在接力跑圈。
Claude Code 团队把它叫作 Turn-based Loop，也就是由一轮轮对话推动的循环。
这种方式非常适合探索性的工作。比如第一次分析一个陌生项目、尝试实现一个新功能、写一篇文章，或者研究一个还没有明确答案的问题。
因为任务刚开始的时候，我们自己可能也不知道最终应该做成什么样。Agent 每完成一步，我们看一下结果，再决定下一步往哪里走。
这时候，人依然是 Loop 里很重要的一环。
问题在于，我们经常重复做相同的检查。
每次 Agent 修改完前端，我都要打开页面，分别检查电脑和手机的显示效果；点击几个按钮；看看浏览器控制台有没有报错；再跑一遍测试。
既然检查流程每次都差不多，就可以把它写成一个 Skill，或者一份固定的验收说明。
以后 Agent 完成修改之后，先按照这份说明自己检查一遍。发现问题就继续改，全部通过以后再来找我。
这样一来，原本需要我亲自完成的一部分 Loop，就被固化进了系统。
这个思路不只适用于代码。写文章也一样。
可以把自己的检查标准写下来：有没有事实错误，开头是不是太慢，有没有重复表达，案例是否真实，是否出现了自己不喜欢的句式。
做数据分析时，也可以要求 Agent 检查数据口径、异常值、时间范围和计算结果。
Skill 的价值，不只是教 Agent 怎么干活，它还可以把我们平时怎么验收工作固化下来。
第二种：目标式 Loop
复杂任务，需要先告诉 Agent 什么叫完成。普通对话式 Loop 有一个很明显的问题：Agent 经常不知道什么时候应该停止。
你让它优化一下这个页面，它改了字体、调整了间距，可能就认为自己已经完成了。
但你心里的优化，可能是让 Lighthouse 分数超过 90，让首屏加载时间低于两秒，或者让所有移动端测试全部通过。
“优化一下”很模糊，“Lighthouse 分数达到 90”就清楚多了。这类任务更适合 Goal-based Loop，也就是目标驱动的循环。
在 Claude Code 里，Anthropic 提供了 /goal。不过这套思路并不属于某个产品。无论使用 Codex、Claude Code，还是自己搭的 Agent，核心都一样：
提前定义一个可以验证的完成条件，让 Agent 没达到目标之前继续工作。
比如：把首页的 Lighthouse 性能分数提高到 90 以上，最多尝试 5 轮。
Agent 每完成一轮修改，都要重新测试。如果分数只有 83，就继续分析瓶颈；达到 91，Loop 才结束。
这里有两个条件。
一个是成功条件：分数达到 90。另一个是兜底条件：最多尝试 5 轮。
只有成功条件，Agent 可能为了一个无法实现的目标不停消耗 Token。只有轮数限制，它又可能在任务还没有真正完成时提前结束。
目标驱动的 Loop，适合所有结果可以明确验收的任务。
代码测试全部通过、页面没有控制台报错、表格中没有空值、迁移的数据量与原系统一致、研究报告覆盖指定的十家公司，都可以成为停止条件。
它和普通 Prompt 最大的差别，在于我们不再只告诉 Agent 做一个动作，还会告诉它做到什么程度。
过去我们经常写：帮我检查一下这个产品。换成 Loop 的思路之后，可能会变成：
分别在电脑端和移动端测试注册、登录、支付和退款流程。每个流程至少覆盖正常路径和一个异常路径。
发现问题后尝试复现，并记录操作步骤、截图和控制台日志。所有测试完成，且每个问题都有明确记录后结束。
Agent 能不能持续工作，很多时候并不取决于模型够不够聪明，关键在于我们有没有把“完成”说清楚。
第三种：定时式 Loop
有些任务一次做完就结束了，还有一些任务会按照固定节奏反复出现。
比如每天早上汇总昨天的行业新闻，每半个小时查看一次 CI，每周整理一次销售数据，或者持续关注客户反馈。
这时，Loop 需要解决另一个问题：什么时候开始下一轮？
最简单的方式是按照时间触发。
在 Claude Code 中，可以用 /loop 每隔一段时间重复执行同一个任务，也可以通过 /schedule 把它放到云端长期运行。
其他 Agent 产品里，可能叫定时任务、自动化或者 Routine，名字不同，逻辑差不多。
假设一个 PR 正在等待审核，可以让 Agent 每隔十分钟检查一次：
如果收到新的 Review 评论，就读取评论、修改代码并重新提交；如果 CI 失败，就查看日志并尝试修复；如果 PR 已经合并，Loop 自动结束。
这种方式特别适合需要和外部系统打交道的工作。因为外部状态一直在变化，Agent 必须隔一段时间看一眼，才能知道要不要行动。
不过，定时检查也很容易浪费 Token。如果一个频道一天只有几条新消息，却让 Agent 每分钟检查一次，大部分运行都没什么实际价值。
所以，能用事件触发的地方，最好用事件触发。
收到新邮件时启动、出现新的 Issue 时启动、CI 失败时启动，通常比不断轮询更省 Token。
暂时接不上事件系统，再考虑定时检查。检查频率也要根据实际变化速度来设置。
第四种：流水线 Loop
再往前一步，就是 Proactive Loop，也就是流水线 Loop。
这时候，Loop 不再只负责重复一个动作，而是变成一条长期运行的工作流水线。
比如，公司有一个产品反馈频道。过去每天都需要有人进去查看消息，把反馈分成 Bug、功能建议和使用问题，再分别转给产品、研发或客服。
如果使用 Proactive Loop，可以把整套流程连起来：
系统收到新反馈后，Agent 自动读取内容，判断类型，检查是否存在重复问题。
如果是 Bug，就尝试复现，收集日志，创建 Issue；如果能够明确定位，就让 Coding Agent 创建分支并尝试修复。
另一个 Agent 负责 Review；确认无误后，再给用户回复处理进展。人不需要在每一个步骤中点一下继续。
只有遇到高风险操作、信息不足或者多个方案难以取舍时，Agent 才把任务交回来。
这类 Loop 的特点，是输入会源源不断地出现，但处理流程相对稳定。Bug 分拣、数据迁移、发票处理、客户反馈、内容审核，都很适合这种模式。
Loop 的演进过程，本质上是人逐渐退出执行链路的过程。但退出不等于完全不管。
人的工作会往前移动到：设计流程、定义边界、写验收标准、处理例外情况。
Loop 怎么保证质量
Loop 最危险的地方，是它会放大系统原有的问题。
一次调用做错了，可能只产生一个错误结果。一个长期运行的 Loop 如果缺少检查，可能连续制造几百个错误。
所以，Loop 只是一个不断重复执行的壳。真正决定质量的，是周围的环境。
做 Coding Loop 时，代码库本身要尽量干净，目录、命名和测试方式要保持一致。Agent 很擅长模仿已有代码。
项目里到处都是临时方案，它也会继续生成临时方案。
文档也要放在 Agent 容易找到的位置。使用什么框架、接口如何调用、哪些目录不能修改、发布流程是什么，都应该写清楚。
更重要的是，Agent 必须有办法看到自己的结果。
比如修改网页之后，要能打开浏览器实际操作一遍。
写完代码要能跑测试，生成数据要能用脚本核对。做 Research 也一样，最后要能回到原始来源逐项检查。
很多任务失败，并非 Agent 不会做，而是它做完以后看不到结果，只能凭感觉宣布完成。
对于重要任务，还可以引入第二个 Agent 做 Review。
负责写代码的 Agent 容易顺着自己的思路继续往下走。换一个拥有全新上下文的 Agent 检查，更容易发现遗漏。写作、研究和数据分析同样可以这样做。
一个 Agent 负责生产，另一个 Agent 负责挑错，最后再由规则或人做决定。
还有一个很重要的习惯：某次 Loop 出错以后，不要只修这一次的结果。
需要继续追问：为什么系统没有提前发现？能不能增加一条测试？能不能把判断标准写进 Skill？能不能增加一个必须经过的 Review 环节？
这样，每次失败都能让下一轮 Loop 更稳定。
设计 Loop，也是在设计成本
Agent 可以无限尝试，钱不可以无限烧。
Loop 最容易出现的情况，就是任务目标模糊、停止条件缺失，几个 Agent 互相讨论了很久，最后没有产生多少有效结果。
控制成本，第一步仍然是缩小任务。
能一次调用解决的问题，没有必要启动三个 Agent。能够用脚本完成的固定动作，也不要每次都让模型重新推理。
比如把数据转换成固定格式，写一个脚本通常更快、更稳定。Agent 只负责判断什么时候运行脚本、参数应该填什么，以及运行失败以后如何处理。
模型也可以分层使用。
读取消息、提取字段这类固定动作，可以交给更快更便宜的模型。遇到架构层面的判断或者比较复杂的排错，再用能力更强的模型来处理。
对于批量任务，先拿十条数据试跑一下。确认效果和成本之后，再扩大到一千条。不要一上来就让动态工作流启动几百个 Agent。
一个可靠的 Loop，通常都带着明确的边界：最多运行多少轮、最多处理多少条、消耗达到多少时暂停、哪些操作必须经过人确认。
没有边界的自动化，很容易从生产力工具变成 Token 粉碎机。
怎么开始第一个 Loop？
我觉得不用一开始就搭一套庞大的多 Agent 系统。
先观察自己每天的工作，找到那个反复出现、结构比较稳定，又总需要自己盯着的环节。
可能是每次发布文章之前检查错别字和事实，可能是每天整理客户反馈，也可能是代码修改完成后反复测试几个页面。
然后把这件事拆成几个问题：
什么情况会触发它？Agent 每一轮需要完成什么？它如何看到并验证结果？什么条件代表任务完成？最多允许尝试多少次？什么情况必须停下来找人接管？
甚至可以直接套用一个很简单的模板：
当某件事发生时，Agent 执行某项工作。完成后使用某种方法检查结果。
如果没有通过，就根据反馈继续修改，最多重试若干次。满足某个条件后结束。遇到某类风险或不确定情况时，交给人处理。
先跑起来，再观察它容易卡在哪里，又会在哪些地方冲得太快，然后不断补充工具、验收条件和边界。
过去，我们使用 Agent，更多是在研究一句 Prompt 应该怎么写。到了 Loop 这一步，我们开始设计一整段工作该怎么持续运行。
Prompt 决定 Agent 这一轮做什么。Loop 决定它如何根据结果继续工作，什么时候再次启动，又在什么地方真正停下来。
推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。现在 6 折售票中。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
aimakersummit.com
1 01
想在上海认真办一场 AI 大会。
Open mind for a different view。这句话一直放在我的置顶备忘录里。
因为人很容易慢慢变得封闭。我们会形成一套自己的认知体系，然后待在里面，觉得一切都很合理。
我其实是一个典型的 I 人。最舒服的状态，就是一个人待着，写东西、看东西，沉浸在自己的世界里。
但我也会刻意提醒自己，要走出去，和不同的人聊聊天，让一些新的东西重新进入自己的思考。
就像华为的人经常说的那样，一杯咖啡吸收宇宙能量。多喝咖啡，多交流，增长见识。
这也是 AI Maker Summit 想做的事情。
这一次，我们把 AI Maker Summit 带到了上海，希望在这里聚集一群有活力的 AI Maker。
门票不贵，300 多块钱。在北上广这样的城市，也就是请人吃顿饭的价格。
今天是上海站早鸟价今天最后一天。
这些内容会覆盖 AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资这些话题。
一天时间，4 个分会场并行，一共 36 个 Talk。我们希望大家这趟不白来，能尽可能多地接触到这个行业里最新鲜的实践和思考。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
其中两个专题，我们拆成了 20 分钟的小演讲。这样能请到更多的创业者和 AI Maker，让他们来分享最新的实践和思考。
内容层面也有变化。除了出品人把关，这次加入了用户评审。每个专题我们会邀请两位资深用户，一起来梳理最终的议题。
讲什么内容，怎么讲，不只是我们团队说了算，而是跟社区一起共建，做出来大家更有价值感的内容。咱不能浪费大家的时间和信任。
再说说请讲师的标准。可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
我也花了不少功夫，专门去找一些还处在非共识阶段的创业者和 AI Maker。就是他们正在做的事情，此刻大部分人还没觉得重要，甚至觉得没必要。
但我跟他们聊完之后发现，这些人想问题的方式跟主流完全不一样，而且已经在用自己的方式跑出了结果。如果只请已经被验证过的人来讲，那听到的都是已知的东西。我更想让大家看到一些还没有被看到的可能性。
我们在 AI Maker Summit 等你。
早鸟价今天最后一天。明天涨价到 399 元。
aimakersummit.com
看了下日历，大会举办完之后，很快就是中秋节了。好像过了中秋节，这一年也就进入了收尾阶段。
兴许，我们可以给自己创造一个机会，让自己离开日常的工作和琐事，去看看这个行业正在发生什么，看看那些有趣的人在折腾什么，顺便想想，自己能用 AI 的杠杆，撬动些什么。
Open mind for a different view。这句话一直放在我的置顶备忘录里。
因为人很容易慢慢变得封闭。我们会形成一套自己的认知体系，然后待在里面，觉得一切都很合理。
我其实是一个典型的 I 人。最舒服的状态，就是一个人待着，写东西、看东西，沉浸在自己的世界里。
但我也会刻意提醒自己，要走出去，和不同的人聊聊天，让一些新的东西重新进入自己的思考。
就像华为的人经常说的那样，一杯咖啡吸收宇宙能量。多喝咖啡，多交流，增长见识。
这也是 AI Maker Summit 想做的事情。
这一次，我们把 AI Maker Summit 带到了上海，希望在这里聚集一群有活力的 AI Maker。
门票不贵，300 多块钱。在北上广这样的城市，也就是请人吃顿饭的价格。
今天是上海站早鸟价今天最后一天。
这些内容会覆盖 AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资这些话题。
一天时间，4 个分会场并行，一共 36 个 Talk。我们希望大家这趟不白来，能尽可能多地接触到这个行业里最新鲜的实践和思考。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
其中两个专题，我们拆成了 20 分钟的小演讲。这样能请到更多的创业者和 AI Maker，让他们来分享最新的实践和思考。
内容层面也有变化。除了出品人把关，这次加入了用户评审。每个专题我们会邀请两位资深用户，一起来梳理最终的议题。
讲什么内容，怎么讲，不只是我们团队说了算，而是跟社区一起共建，做出来大家更有价值感的内容。咱不能浪费大家的时间和信任。
再说说请讲师的标准。可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
我也花了不少功夫，专门去找一些还处在非共识阶段的创业者和 AI Maker。就是他们正在做的事情，此刻大部分人还没觉得重要，甚至觉得没必要。
但我跟他们聊完之后发现，这些人想问题的方式跟主流完全不一样，而且已经在用自己的方式跑出了结果。如果只请已经被验证过的人来讲，那听到的都是已知的东西。我更想让大家看到一些还没有被看到的可能性。
我们在 AI Maker Summit 等你。
早鸟价今天最后一天。明天涨价到 399 元。
aimakersummit.com
看了下日历，大会举办完之后，很快就是中秋节了。好像过了中秋节，这一年也就进入了收尾阶段。
兴许，我们可以给自己创造一个机会，让自己离开日常的工作和琐事，去看看这个行业正在发生什么，看看那些有趣的人在折腾什么，顺便想想，自己能用 AI 的杠杆，撬动些什么。
0 00
吴恩达对 Loop Engineering 的理解真深刻。
Andrew Ng 对 Loop Engineering 的理解好深刻。
上午一到公司，就看到他在 X 上发了一篇长文，讲了自己最近的一些判断。
我一直觉得大家最近聊 Loop Engineering，更多还是在聊工程上的 loop，比如 Agent 怎么自己写代码、自己调试、自己修 Bug。
但 Andrew Ng 把这个概念又往外扩了一层。
他觉得，当 AI 能够自主写代码之后，真正发生变化的不是工程效率，而是整个软件开发开始变成三种不同时间尺度的 Loop 同时运转：
最里层是 AI 自己不断迭代代码，中间是开发者持续修正产品方向，最外层则是真实用户和市场环境不断修正开发者的判断。
这三个 Loop，一层比一层慢，但也一层比一层重要。
01 Agentic Coding Loop：AI 自己跑起来的工程循环
最里层，就是现在大家最熟悉、也最爱拿出来炫技的部分：AI Agent 自己写代码。
做法其实不复杂。给它一份产品文档，也就是 Spec，再配一套评测标准，也就是 Evals，Agent 就能自己动手。
写代码、跑测试、发现问题继续修改，改完再测，一圈一圈转下去，直到基本符合规格、没有明显 Bug 为止。
Andrew Ng 举了个最近的例子。他周末想给女儿做一个练打字的小程序，让 Agent 连续干了差不多一个小时，中间还自己打开浏览器，把刚写好的页面点开来看了好几遍，确认没问题才回来找他汇报。
整个过程他几乎没插手，不用像以前那样每隔几分钟就得点一下重试。Agent 已经能够独立验证自己的结果。
过去做代码生成，更像一次性的互动。问一句给一段，人得一直盯着，本质上还是人在转方向盘，AI 负责踩油门。
但当写代码、跑测试、发现问题、继续修改，这整个闭环真正跑起来之后，Agent 就从一个问答工具，变成了一个能够持续自我纠偏的小系统。
这才是过去一年 AI Coding 生产力跳升的重要原因。模型能力当然在进步，但真正拉开差距的，是 Agent 学会了自己检查、自己验证。
而且这一层循环远没有定型。怎么写更聪明的测试，怎么搭更顺畅的自动调试链路，怎么让 Agent 在一小时的连续工作里少走弯路，这些都还是今天大家不断探索的问题。
不过，Loop Engineering 转得再快，它始终回答不了一个问题：到底应该写什么。
Agent 可以不断优化答案，却不知道什么才是真正的问题。
产品方向、需求边界、哪些功能值得做，这些决定仍然来自人。这也就是第二层 Loop 存在的原因。
02 Developer Feedback Loop：开发者负责修正方向
第二层循环的主角重新变回了人。
跟第一层最大的区别在于，第一层里，人可以离开，Agent 自己就能跑起来；第二层里，人不能离开，因为这一层做的是判断。
开发者在这里已经不是替 AI 揪 Bug，那些工作 Agent 自己已经完成得越来越好了。
人开始做更上层的事情：决定功能范围，调整 UI 和交互，重新思考信息怎么组织，看完 Agent 做出来的第一版之后，再回头修改最初的 Spec，甚至整个推翻重来。
Andrew Ng 提到，去年这个时候，包括他自己在内，很多开发者其实都在给 Agent 当 QA，自己测试产品、找 Bug，再让 Agent 去修。
一年过去，Agent 自测和自我修复能力越来越强，人花在挑错上的时间少了很多，于是精力自然开始往更高层的产品判断上走。
打字 App 那个例子里，他真正花时间做的是反复调整视觉风格，琢磨女儿能解锁哪些猫咪皮肤（她喜欢猫），重新设计家长登录和监督学习进度的整个流程。这些都是方向性的决策。
这一层循环的节奏，大概是几十分钟到几个小时。开发者隔一段时间回来看看当前版本，再决定下一步往哪走。
真正费劲的地方，在于把脑子里一个模模糊糊的想法，变成 Agent 能执行的 Spec。而且很多时候，Spec 并不是一开始就写好的。
越来越真实的过程是：先写一个比较粗糙的 Spec，让 Agent 做出第一版，看完之后才发现自己真正想要的是另外一种东西，于是回头继续改 Spec，再继续生成。
如果某类问题反反复复出现，这时候再补上一套 Evals，当成后续自动迭代的质量锚点，省得每次都人工盯着同一个坑。
Andrew Ng 在这里还提了一个我觉得很有意思的观点。
很多人喜欢说，人类在产品上的优势来自品味。他更愿意把它理解成上下文优势。
因为品味听起来很玄，但上下文可以拆开来看：用户是谁、业务边界是什么、有哪些约束条件、竞争对手在做什么。
这些信息目前还锁在人脑子里，AI 并不知道。
所以，只要人类还掌握着 Agent 不知道的上下文，人就必须留在这个 Loop 里，把这些信息一点点补给系统。
不过，开发者的判断再好，也始终有一个局限。它终究还是基于自己的想象。
真正的用户会怎么用，市场会怎么变化，竞品昨天是不是刚发布了一个新功能，这些事情，只有产品真正进入真实世界之后才能知道。
于是，就来到了第三层 Loop。
03 External Feedback Loop：来自真实世界的慢反馈
第三层循环发生在产品之外。
比如找几个朋友试用一下，收集真实反馈。邀请一批 Alpha 或 Beta 用户。或者直接上线，通过 A/B Test 和后台数据观察用户行为。
这些方法都有一个共同特点：慢。
很少有几个小时就能看到结果的，更多时候要等几天，甚至几周。
相比前两层以分钟和小时为单位高速运转，这一层几乎像静止一样。
但偏偏，它承担着最重要的纠偏工作。因为前两层都发生在系统内部。Agent 按照 Spec 写代码，开发者按照自己的理解修改 Spec，但两者都没有真正接触真实用户。
用户会不会理解你的设计？市场是不是已经发生变化？竞争环境有没有改变用户预期？这些问题，没有任何人能够坐在办公室里想出来。
只能放到真实世界里，才能拿到答案。
而且，这一层反馈不会直接修改代码。它会先回到开发者脑子里，修正开发者对产品的整体判断，也就是 Vision。开发者再根据新的判断调整 Spec，最后交给 Agent 去执行。
三层 Loop，就是这样串起来的。
最慢的一层提供信号，中间那层负责判断，最快的一层负责执行。
我觉得，这也是 AI 正在悄悄改变工程师角色的地方。
随着 Agent 把开发速度不断推高，越来越多工程师开始承担一部分产品经理的工作。
一头要把模糊的 Vision 翻译成 Agent 能执行的 Spec；另一头要不断听真实用户的反馈，再回过头修正自己的 Vision。
AI 并没有消灭软件开发中的 Loop，它只是把最里面那层 Loop 压缩到了几分钟。
于是，软件开发真正稀缺的能力，开始越来越往外层迁移。
真正难的是，想清楚到底要解决什么问题，把一个模糊的想法不断修正成 Agent 能执行的 Spec，再持续从真实世界拿回反馈，修正自己的判断。
这三层 Loop，一层比一层慢，也一层比一层重要。少了任何一层，一个真正的 0 到 1 产品，都很难跑起来。
最后，推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。早鸟价下周结束。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网：aimakersummit.com
Andrew Ng 对 Loop Engineering 的理解好深刻。
上午一到公司，就看到他在 X 上发了一篇长文，讲了自己最近的一些判断。
我一直觉得大家最近聊 Loop Engineering，更多还是在聊工程上的 loop，比如 Agent 怎么自己写代码、自己调试、自己修 Bug。
但 Andrew Ng 把这个概念又往外扩了一层。
他觉得，当 AI 能够自主写代码之后，真正发生变化的不是工程效率，而是整个软件开发开始变成三种不同时间尺度的 Loop 同时运转：
最里层是 AI 自己不断迭代代码，中间是开发者持续修正产品方向，最外层则是真实用户和市场环境不断修正开发者的判断。
这三个 Loop，一层比一层慢，但也一层比一层重要。
01 Agentic Coding Loop：AI 自己跑起来的工程循环
最里层，就是现在大家最熟悉、也最爱拿出来炫技的部分：AI Agent 自己写代码。
做法其实不复杂。给它一份产品文档，也就是 Spec，再配一套评测标准，也就是 Evals，Agent 就能自己动手。
写代码、跑测试、发现问题继续修改，改完再测，一圈一圈转下去，直到基本符合规格、没有明显 Bug 为止。
Andrew Ng 举了个最近的例子。他周末想给女儿做一个练打字的小程序，让 Agent 连续干了差不多一个小时，中间还自己打开浏览器，把刚写好的页面点开来看了好几遍，确认没问题才回来找他汇报。
整个过程他几乎没插手，不用像以前那样每隔几分钟就得点一下重试。Agent 已经能够独立验证自己的结果。
过去做代码生成，更像一次性的互动。问一句给一段，人得一直盯着，本质上还是人在转方向盘，AI 负责踩油门。
但当写代码、跑测试、发现问题、继续修改，这整个闭环真正跑起来之后，Agent 就从一个问答工具，变成了一个能够持续自我纠偏的小系统。
这才是过去一年 AI Coding 生产力跳升的重要原因。模型能力当然在进步，但真正拉开差距的，是 Agent 学会了自己检查、自己验证。
而且这一层循环远没有定型。怎么写更聪明的测试，怎么搭更顺畅的自动调试链路，怎么让 Agent 在一小时的连续工作里少走弯路，这些都还是今天大家不断探索的问题。
不过，Loop Engineering 转得再快，它始终回答不了一个问题：到底应该写什么。
Agent 可以不断优化答案，却不知道什么才是真正的问题。
产品方向、需求边界、哪些功能值得做，这些决定仍然来自人。这也就是第二层 Loop 存在的原因。
02 Developer Feedback Loop：开发者负责修正方向
第二层循环的主角重新变回了人。
跟第一层最大的区别在于，第一层里，人可以离开，Agent 自己就能跑起来；第二层里，人不能离开，因为这一层做的是判断。
开发者在这里已经不是替 AI 揪 Bug，那些工作 Agent 自己已经完成得越来越好了。
人开始做更上层的事情：决定功能范围，调整 UI 和交互，重新思考信息怎么组织，看完 Agent 做出来的第一版之后，再回头修改最初的 Spec，甚至整个推翻重来。
Andrew Ng 提到，去年这个时候，包括他自己在内，很多开发者其实都在给 Agent 当 QA，自己测试产品、找 Bug，再让 Agent 去修。
一年过去，Agent 自测和自我修复能力越来越强，人花在挑错上的时间少了很多，于是精力自然开始往更高层的产品判断上走。
打字 App 那个例子里，他真正花时间做的是反复调整视觉风格，琢磨女儿能解锁哪些猫咪皮肤（她喜欢猫），重新设计家长登录和监督学习进度的整个流程。这些都是方向性的决策。
这一层循环的节奏，大概是几十分钟到几个小时。开发者隔一段时间回来看看当前版本，再决定下一步往哪走。
真正费劲的地方，在于把脑子里一个模模糊糊的想法，变成 Agent 能执行的 Spec。而且很多时候，Spec 并不是一开始就写好的。
越来越真实的过程是：先写一个比较粗糙的 Spec，让 Agent 做出第一版，看完之后才发现自己真正想要的是另外一种东西，于是回头继续改 Spec，再继续生成。
如果某类问题反反复复出现，这时候再补上一套 Evals，当成后续自动迭代的质量锚点，省得每次都人工盯着同一个坑。
Andrew Ng 在这里还提了一个我觉得很有意思的观点。
很多人喜欢说，人类在产品上的优势来自品味。他更愿意把它理解成上下文优势。
因为品味听起来很玄，但上下文可以拆开来看：用户是谁、业务边界是什么、有哪些约束条件、竞争对手在做什么。
这些信息目前还锁在人脑子里，AI 并不知道。
所以，只要人类还掌握着 Agent 不知道的上下文，人就必须留在这个 Loop 里，把这些信息一点点补给系统。
不过，开发者的判断再好，也始终有一个局限。它终究还是基于自己的想象。
真正的用户会怎么用，市场会怎么变化，竞品昨天是不是刚发布了一个新功能，这些事情，只有产品真正进入真实世界之后才能知道。
于是，就来到了第三层 Loop。
03 External Feedback Loop：来自真实世界的慢反馈
第三层循环发生在产品之外。
比如找几个朋友试用一下，收集真实反馈。邀请一批 Alpha 或 Beta 用户。或者直接上线，通过 A/B Test 和后台数据观察用户行为。
这些方法都有一个共同特点：慢。
很少有几个小时就能看到结果的，更多时候要等几天，甚至几周。
相比前两层以分钟和小时为单位高速运转，这一层几乎像静止一样。
但偏偏，它承担着最重要的纠偏工作。因为前两层都发生在系统内部。Agent 按照 Spec 写代码，开发者按照自己的理解修改 Spec，但两者都没有真正接触真实用户。
用户会不会理解你的设计？市场是不是已经发生变化？竞争环境有没有改变用户预期？这些问题，没有任何人能够坐在办公室里想出来。
只能放到真实世界里，才能拿到答案。
而且，这一层反馈不会直接修改代码。它会先回到开发者脑子里，修正开发者对产品的整体判断，也就是 Vision。开发者再根据新的判断调整 Spec，最后交给 Agent 去执行。
三层 Loop，就是这样串起来的。
最慢的一层提供信号，中间那层负责判断，最快的一层负责执行。
我觉得，这也是 AI 正在悄悄改变工程师角色的地方。
随着 Agent 把开发速度不断推高，越来越多工程师开始承担一部分产品经理的工作。
一头要把模糊的 Vision 翻译成 Agent 能执行的 Spec；另一头要不断听真实用户的反馈，再回过头修正自己的 Vision。
AI 并没有消灭软件开发中的 Loop，它只是把最里面那层 Loop 压缩到了几分钟。
于是，软件开发真正稀缺的能力，开始越来越往外层迁移。
真正难的是，想清楚到底要解决什么问题，把一个模糊的想法不断修正成 Agent 能执行的 Spec，再持续从真实世界拿回反馈，修正自己的判断。
这三层 Loop，一层比一层慢，也一层比一层重要。少了任何一层，一个真正的 0 到 1 产品，都很难跑起来。
最后，推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。早鸟价下周结束。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网：aimakersummit.com
0 00
Claude Code 创始人：我有一种非常强烈的感受。
Claude Code 的创始人 Boris Cherny 发了一条高赞的推文，大致意思是：
随着工程、产品、设计、数据科学等岗位融合成一种新型角色，我一直在思考未来的岗位形态会是怎样。
比如，观察 Claude Code 团队，我认为能看到五种典型角色：
1、Prototyper：提出全新的想法，产出大量创意，其中大部分不会落地
2、Builder：快速将原型/想法转化为可投入生产的产品或基础设施
3、Sweeper：打磨用户界面、简化代码与系统、下架无用内容、优化性能
4、Grower：接手已打造的产品，通过持续迭代优化产品与市场的契合度
5、Maintainer：负责成熟的系统，确保其在规模扩大时依然安全、可靠、快速且高效
很多人会同时承担两种角色，有时甚至是三种。
而且这些角色其实和具体的职能岗位没有必然关联，比如在 Anthropic，有些设计师属于第一种类型，有些属于第二种，还有些属于第三种。工程师、产品经理、数据科学家也是如此。
一支健康的团队需要根据产品阶段搭配不同角色，而且每个人的角色会随着时间和项目不断变化。
1、处于早期且未达成产品市场契合度的产品，需要擅长 1+2+3 类能力的人
2、处于成长期且已达成产品市场契合度的产品，需要 2+3+4 类角色，再搭配少量 5 类角色
3、产品市场契合度较高的成熟产品，需要 3+4+5 类角色，再搭配少量 2 类角色
这条推文之所以能引发这么多讨论，核心还是现在大公司内部的工程师、产品经理、数据分析师等等这些在上一个时代形成的角色分工，有了 AI 之后多少都会有些迷惑。
每个角色能做的事确实变多了。很多产品经理也开始写代码、写自动化脚本，工程师会直接改 UI、做交互实验，设计师会用 AI 快速出可交互的 Demo。
与此同时，团队里某些传统角色正在被折叠。最近一段时间很多大厂在裁员，我觉得裁员也和这种变化有一定关系。
Boris 的思路是，可以先放下前端、后端、产品这种按专业技能拆分的分工方式。
我怎么记得好像华为之前特爱干这事？早年看过一些华为的书，他们经常会重新基于产品的流程，调整岗位的职责。
当然有人会说，这不就是新瓶装旧酒吗？Prototyper 对应客户需求加产品经理，Builder 对应架构师，Sweeper 对应软件工程师....
这话有一点道理，毕竟这些事情过去确实都存在。
但问题是，AI 已经把这些事情之间的边界打破了。以前一个想法从产生到上线，中间可能要经过很多专业的工种。
现在，AI 把某些角色折叠了，流水线上需要的工种更少，每个人的 range 会更大。甚至，像我这样的创业公司，前三个岗位都会整合为 Builder。
就像上周我给大家举的例子，我们团队之前的产品开发流程是：
调研 → 写一堆 PRD / 文档 → 评审 → 设计 → 再评审 → 开发 → 测试 → 上线。
过去产品经理启动一个需求，起点就是写文档。调研、写文档、评审、设计，这条链路走下来，光前期就要花很长时间。
而且产品文档这个东西，写的人痛苦，看的人也未必能耐心看，动不动几千字，真正认真读的人没几个。
现在我们的做法是，产品经理不用先写文档，直接用 AI 做原型。
跟用户沟通用这个原型，跟程序员沟通也用原型，这样就能省掉一大段冗余环节，关键是这样做沟通也会更高效。
文档我们还是有的，但变成后置的。评审完之后，把其中的关键逻辑写清楚就行。不需要啰嗦，控制在 1000 字。确实，流程在变，角色的定义也在变。
最后，推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。早鸟价马上结束。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网：aimakersummit.com
Claude Code 的创始人 Boris Cherny 发了一条高赞的推文，大致意思是：
随着工程、产品、设计、数据科学等岗位融合成一种新型角色，我一直在思考未来的岗位形态会是怎样。
比如，观察 Claude Code 团队，我认为能看到五种典型角色：
1、Prototyper：提出全新的想法，产出大量创意，其中大部分不会落地
2、Builder：快速将原型/想法转化为可投入生产的产品或基础设施
3、Sweeper：打磨用户界面、简化代码与系统、下架无用内容、优化性能
4、Grower：接手已打造的产品，通过持续迭代优化产品与市场的契合度
5、Maintainer：负责成熟的系统，确保其在规模扩大时依然安全、可靠、快速且高效
很多人会同时承担两种角色，有时甚至是三种。
而且这些角色其实和具体的职能岗位没有必然关联，比如在 Anthropic，有些设计师属于第一种类型，有些属于第二种，还有些属于第三种。工程师、产品经理、数据科学家也是如此。
一支健康的团队需要根据产品阶段搭配不同角色，而且每个人的角色会随着时间和项目不断变化。
1、处于早期且未达成产品市场契合度的产品，需要擅长 1+2+3 类能力的人
2、处于成长期且已达成产品市场契合度的产品，需要 2+3+4 类角色，再搭配少量 5 类角色
3、产品市场契合度较高的成熟产品，需要 3+4+5 类角色，再搭配少量 2 类角色
这条推文之所以能引发这么多讨论，核心还是现在大公司内部的工程师、产品经理、数据分析师等等这些在上一个时代形成的角色分工，有了 AI 之后多少都会有些迷惑。
每个角色能做的事确实变多了。很多产品经理也开始写代码、写自动化脚本，工程师会直接改 UI、做交互实验，设计师会用 AI 快速出可交互的 Demo。
与此同时，团队里某些传统角色正在被折叠。最近一段时间很多大厂在裁员，我觉得裁员也和这种变化有一定关系。
Boris 的思路是，可以先放下前端、后端、产品这种按专业技能拆分的分工方式。
我怎么记得好像华为之前特爱干这事？早年看过一些华为的书，他们经常会重新基于产品的流程，调整岗位的职责。
当然有人会说，这不就是新瓶装旧酒吗？Prototyper 对应客户需求加产品经理，Builder 对应架构师，Sweeper 对应软件工程师....
这话有一点道理，毕竟这些事情过去确实都存在。
但问题是，AI 已经把这些事情之间的边界打破了。以前一个想法从产生到上线，中间可能要经过很多专业的工种。
现在，AI 把某些角色折叠了，流水线上需要的工种更少，每个人的 range 会更大。甚至，像我这样的创业公司，前三个岗位都会整合为 Builder。
就像上周我给大家举的例子，我们团队之前的产品开发流程是：
调研 → 写一堆 PRD / 文档 → 评审 → 设计 → 再评审 → 开发 → 测试 → 上线。
过去产品经理启动一个需求，起点就是写文档。调研、写文档、评审、设计，这条链路走下来，光前期就要花很长时间。
而且产品文档这个东西，写的人痛苦，看的人也未必能耐心看，动不动几千字，真正认真读的人没几个。
现在我们的做法是，产品经理不用先写文档，直接用 AI 做原型。
跟用户沟通用这个原型，跟程序员沟通也用原型，这样就能省掉一大段冗余环节，关键是这样做沟通也会更高效。
文档我们还是有的，但变成后置的。评审完之后，把其中的关键逻辑写清楚就行。不需要啰嗦，控制在 1000 字。确实，流程在变，角色的定义也在变。
最后，推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。早鸟价马上结束。这次邀请到了不少一线的实战讲师，内容非常有料。
大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网：aimakersummit.com
0 00
传统的Benchmark太容易作弊了。
Benchmark 很容易被刷。更准确地说，是这类 Benchmark 已经不能反映模型的实际能力了。
刚看了 OpenAI 研究员 Noam 的访谈。这哥们我一直关注，讲东西言之有物。
他上来就把矛头对准了现在行业里最常见的 Benchmark 表格。横轴是各种任务，纵轴是不同模型，每个格子里填一个分数。说这玩意已经过时了。
他举了一个很具体的例子。o3-pro 发布的时候，很多人看 Benchmark 表格觉得比上一代提升不大，有些项目只多了几个百分点，于是就觉得没什么进步。
但实际用下来感受完全不同。原因是 o3-pro 的思考效率更高，用更少的算力就能达到同样甚至更好的表现。一旦把算力这个变量控制住，提升其实很明显。但表格上看不出来。
问题的根源在于，这种分数默认假设每道题花的算力差不多，思考时间也差不多。
在 GPT-3 的时代，这还算合理，因为那时候就算给模型一千万美元的预算，它也做不了什么更多的事情，大家每次跑测试的算力开销确实差不多。
但现在不一样了。同一个模型，可以让它想 1 秒，也可以让它想 1 分钟，甚至想几个小时、想一周，只要愿意付出这些时间和算力。模型的表现跟推理时投入的算力直接相关。
所以之前的 Benchmark 就很扯了。
它缺了一个关键维度：算力预算。一个模型只要给它更多的算力去跑，就有可能跑出更好的结果，就有可能比别的模型分数更高。
Noam 的说法是，整个行业现在陷入了一种坏均衡。所有人都知道这张表格有问题，但所有人都还在发，因为大家都觉得别人期待看到这张表。没人愿意先打破它。
正确的做法是把算力预算加进去。
第一种方案是固定算力预算，比如统一规定 Token 上限或者时间上限，然后再跑 Benchmark。
但算力预算这事又不好规范，因为每个模型的 Token 效率不一样。
所以 OpenAI 目前在尝试另一种思路，针对一个具体场景，X 轴是投入的推理算力，Y 轴是任务表现。这样才能看到一个模型在这个场景里真实的能力分布。
不过，又引出来另外一个问题，模型大概率是推理时间越长、效果越好。但日常使用中不可能无限等待......
----
最后，推荐我们在上海举办的 AI Maker Summit 大会。早鸟价马上结束。这次邀请到了不少一线的实战讲师，内容非常有料。
aimakersummit.com
Benchmark 很容易被刷。更准确地说，是这类 Benchmark 已经不能反映模型的实际能力了。
刚看了 OpenAI 研究员 Noam 的访谈。这哥们我一直关注，讲东西言之有物。
他上来就把矛头对准了现在行业里最常见的 Benchmark 表格。横轴是各种任务，纵轴是不同模型，每个格子里填一个分数。说这玩意已经过时了。
他举了一个很具体的例子。o3-pro 发布的时候，很多人看 Benchmark 表格觉得比上一代提升不大，有些项目只多了几个百分点，于是就觉得没什么进步。
但实际用下来感受完全不同。原因是 o3-pro 的思考效率更高，用更少的算力就能达到同样甚至更好的表现。一旦把算力这个变量控制住，提升其实很明显。但表格上看不出来。
问题的根源在于，这种分数默认假设每道题花的算力差不多，思考时间也差不多。
在 GPT-3 的时代，这还算合理，因为那时候就算给模型一千万美元的预算，它也做不了什么更多的事情，大家每次跑测试的算力开销确实差不多。
但现在不一样了。同一个模型，可以让它想 1 秒，也可以让它想 1 分钟，甚至想几个小时、想一周，只要愿意付出这些时间和算力。模型的表现跟推理时投入的算力直接相关。
所以之前的 Benchmark 就很扯了。
它缺了一个关键维度：算力预算。一个模型只要给它更多的算力去跑，就有可能跑出更好的结果，就有可能比别的模型分数更高。
Noam 的说法是，整个行业现在陷入了一种坏均衡。所有人都知道这张表格有问题，但所有人都还在发，因为大家都觉得别人期待看到这张表。没人愿意先打破它。
正确的做法是把算力预算加进去。
第一种方案是固定算力预算，比如统一规定 Token 上限或者时间上限，然后再跑 Benchmark。
但算力预算这事又不好规范，因为每个模型的 Token 效率不一样。
所以 OpenAI 目前在尝试另一种思路，针对一个具体场景，X 轴是投入的推理算力，Y 轴是任务表现。这样才能看到一个模型在这个场景里真实的能力分布。
不过，又引出来另外一个问题，模型大概率是推理时间越长、效果越好。但日常使用中不可能无限等待......
----
最后，推荐我们在上海举办的 AI Maker Summit 大会。早鸟价马上结束。这次邀请到了不少一线的实战讲师，内容非常有料。
aimakersummit.com
1 00
Anthropic这期访谈很通透，分享了他们内部的几个核心判断。
听了 Anthropic Claude Code 和 Co-work 负责人 Fiona Fung 的一期播客，收获不小，解答了不少我内心的困惑。
我在创业，也在经历这个时代的巨大转变。每天仍然会碰到不少难题，比如到底找什么样的人更合适，怎么让自己的小公司更加 AI Native。
这些命题我觉得非常重要，因为我们团队小，所以可以更快。如果团队小又慢又不变化，那基本就死路一条。
这些事情最近一直在想，没有答案。这期播客昨天晚上临睡前点开的，今天早上去公司的路上听完了。我觉得所有做管理的同学都可以看看。
www.youtube.com
前十六分钟信息量不高，基本都在说已经是共识的话题，比如 Anthropic 的工程师每个季度的代码产出是之前的 8 倍，编码已经不是瓶颈了。这些大家都知道。
后半部分我非常喜欢，她回答了比如说这个时代 Anthropic 喜欢招什么样的工程师，她们的团队流程和协作方式是怎么变化的。
非常硬核，有很多细节。感觉所有在做管理的同学都可以读读。
什么样的人开始变得值钱？
其实 Anthropic 内部对于优秀工程师的画像也在变化。这件事说出来稀松平常，但猛地回过头看一下，还是挺震惊的。
也就这一两年时间，行业对于优秀程序员的定义已经迅速发生了变化。
Anthropic 喜欢招两类人。
第一类是有产品感的 Creative Builder。
这部分人能够自己构思产品的体验，做原型，看数据的反馈，然后一轮一轮去调整产品，而不只是像传统的很多工程师那样，只负责实现别人的需求。
我也有这个感受。AI 把能力放大之后，一个人的审美、判断力、主动性，反而变得越来越重要。
如果一个人有直觉、有用户意识，确实就更容易做出来更好的东西。
但这样的人非常不好招。我过去也试图从市场找这类选手，反正还没找到。特别优秀的人，要么去了大公司，要么自己创业了。
第二类是在关键领域有很深功底的工程师。
比如分布式系统、底层性能、安全这些难啃的骨头，他们真的懂。模型再强，这些地方仍然需要人脑加经验来做最终的验证和架构决策。
AI 是把写代码的门槛拉低了，但是深度理解系统、搞清楚依赖和约束、知道哪里应该重构、哪些地方有隐形的风险，这种能力和经验在今天反而更加重要。
其实这两类优秀工程师的画像也是接下来大家的职业发展方向。要么你就是成为一个 Creative 的 Builder，要么就是你在某一方面做得足够深。
另外，抛开具体的工程师类型不谈，Anthropic 面试的时候特别看重 Growth Mindset，也就是成长型思维。这个词过去在互联网圈子也用烂了。
我最近面试也特别在意这一点。一个人如果总是不愿意承认自己不懂，其实挺危险的，因为那就意味着在学习方面的动力也不强。
Anthropic 很看重的成长特质是：
1、愿意承认过去这些年让我成功的那一套，在新世界可能不再适用。
2、面对恐惧，不是本能地抵触，而是问：这件事里有哪些部分在我掌控之内，我可以做什么尝试？
3、主动去拥抱变化，哪怕一开始会觉得不适、甚至要有意做一些让自己害怕的职业选择。
这些话听起来翻来覆去就是成长思维、积极主动。
但我作为一家小公司的负责人，真心觉得有这种品质的人难能可贵。一个人如果能有这样的特质，在 AI 时代应该是能够拿到红利的。
团队之间怎么协同？
我管理公司，最大的一个感受就是不希望有管理。招到好的人，根本不需要管理。
像之前很多公司搞打卡、压 KPI，我觉得那是大公司的管理手段。对于中小公司来说，如果一个人需要通过打卡或者 KPI 去驱动，那可能就不适合在这样的环境里生长。
甚至几年前，我在生气的时候还做过一些错误的决策，比如碰到低级的失误扣奖金之类。现在来回想也是很可笑，这完全就是通过管理手段去管理不合适的人。
这两年我主要的管理思路就是不上管理手段，找到合适的人，大家一起自主地往前推进事情。
听播客的时候发现啊， Anthropic 也是类似的文化，当然人家做的更好。
在 Anthropic，高 Agency 和高 Accountability 是绑定在一起的。
所谓高 Agency，可以理解成，每个人都被当成大人，而不是等指令的小孩。每个人有权自己发现问题、自己立项、自己调动 AI 和资源开干。
但只有高 Agency，没有高 Accountability，团队会演变成一锅粥，大家都很忙、都在搞点啥，团队整体容易跑偏，重复造轮子，也没人真对结果负责。
所以，必须得配套有高 Accountability，也就是清清楚楚的责任感和结果导向。团队每个人要对自己推动的事情负责。
举个例子，一个 Claude Code 团队的工程师，发现用户在某个编辑器场景下频繁抱怨卡顿。
低 Agency 团队里，这个人可能会在 Slack 嘟囔几句，“这个体验好差”，然后等 PM/经理开会排期。
或者在只有高 Agency、低 Accountability 的团队里，他可能会：直接重写一堆逻辑，提个 3k 行的 PR，说我觉得这样更好，然后忙其他的事情去了。
而在 Anthropic 这样的高 Agency 和高 Accountability 团队里，工程师会先下判断，诸如我们在 X 场景下的 P95 latency 比竞品慢 30%，这是用户体感到卡的原因。
紧接着自己起手做方案：让 Claude 帮他分析代码路径，找出最可能的瓶颈，设计一两个能快速上线的优化方案。
在这个过程中，他需要同时给自己、也给团队一个很清楚的责任框架：功的定义是什么？
例如：P95 降到多少、负反馈下降多少。最坏的情况是什么？比如：可能引入某类新 bug，要用什么监控和回滚策略兜底。
在 Anthropic，任务的事情，前面都要有一个简短到可以写在一条 Slack 里的问题陈述和假设。就一句话的模板：
1、我认为问题是 X（数据/反馈证据），
2、假设是 Y（我这么相信的理由），
3、实验方式是 Z（怎么上线、怎么监控）。
这样做的好处是，大家提起新想法的频率会变高，但那种拍脑袋、一时兴起的想法，会因为过不了自己心里的那套 accountability 问题，而在很早很轻的阶段就被筛掉。
关于团队中层的变化
我们团队一直是没有中层的。但最近跟一些在国企或者互联网公司做中层的同学吃饭，大家普遍还是焦虑。
因为有了 AI 后，夹在中间的位置，如果只是做信息转发、进度管理、报表汇总，这个价值会被快速压缩。
我们看下 Anthropic 的做法。
新加入的 Manager，不需要立刻进入管理状态，因为这儿其实管理者又不是让你管人，汇报进度。
所以，Manager 加入之后，会有一个阶段只做一线工作，去写代码、看产品、理解工具链。
即使之后进入管理岗位，也不能完全脱离执行层面。比如要自己写 PR，要参与具体的产品构建。
因为如果一个人不直接参与构建，很快就会失去对问题真实形态的感知。
参与过具体的一线工作，Manager 能很快发现那些 PPT 里不会写的坑。
比如脚本不好用、日志查起来很痛苦、一个小改动要过三道流程等等，也能判断哪些是应该靠流程解决的问题，哪些是其实改两行脚本就没了。
这一点对国内中层其实挺有参考价值。
我们绕不开开会、写汇报没关系，但可以给自己压一条底线。每个迭代，至少有一两件具体的事情，是你亲手推到线上，或者亲手走完全流程的。
只要这条底线守住，你就不会彻底变成一个只会转述别人观点的中转站。
她特别害怕那种口头禅是都挺好的管理层。因为你一旦把没问题当成对上对下的统一口径，组织里的讨论就会自动降维：
下面的人开始习惯性报喜不报忧，问题都藏在走廊、饭局和小群里。直到某个时间点，问题爆成事故，才集体发现原来这么多坑。
所以在一对一里她会主动问最近最不爽的三件事是什么，并且刻意把吐槽当成正常输入，而不是当成负能量。
产品团队的一些变化
她心目中健康的产品团队，大概是这样一种状态：
一方面真心欣赏自己做出来的东西：看到用户用得开心，会觉得“这玩意儿挺酷”。
另一方面被它的各种小问题折磨得想骂人：加载慢、按钮偏一点、复制粘贴不灵，都能让你抓狂。
这两种感受叠加在一起，才会让人有动力每天去微调、去打磨。
如果你只剩下骄傲，觉得我们已经很牛了，那就容易目中无人，不尊重市场。如果只剩下厌烦，觉得自己在给一坨垃圾收拾残局，那大概率也撑不久。
一个健康的产品团队，不应该是看起来一切都很好的状态。有问题很正常。
产品节奏这块，Anthropic 最早他们同样搞过六个月的 roadmap，跟移动互联网时代大家熟悉的那一套几乎一模一样。
先把未来半年想做的大方向写下来，然后按季度、按版本节奏去拆解、执行、迭代。
区别在于，他们很快承认了一个现实，在今天这个节奏下，六个月的 roadmap 基本已经失效了。
模型能力每几周迭代一次，竞品不断试新形态，用户的使用方式被新工具牵着往前跑。
你一份半年计划写完三个月，再回头看，多半已经和真实世界脱节。
所以他们干脆把节奏改成了两个齿轮：
外圈是月度规划：每个月定一次大致方向。本月最重要的几件事是什么。就几条，简单粗暴，大家能背得下来。
内圈是每周快节奏沟通：一周一小结，看这个月那几件最重要的事是不是还成立，需要的话直接微调。
我觉得这里最有启发的是他们在流程上的主动减法。感觉任何一家成立三年以上的公司，都会自然长出一堆流程：
评审、汇报、立项模板、对齐会、跨部门机制……
当年长出来的时候，多半都有合理原因，人多了要防混乱，项目多了要防踩坑。
问题在于，这些流程都是在 AI 还没这么能干的前提下设计的。
AI 来了之后，有些工作本身已经可以自动化甚至直接跳过，但我们沿用的可能已经过时的流程还在。Anthropic 的做法有点简单粗暴，但非常有效：
遇到流程，他们反复追问一个问题，这个东西，现在还在为我们服务吗？还是变成了我们在为它服务？
如果答案偏后者，他们的默认选项是考虑直接砍掉重新设计。
我在想，可以把这套思路类推到自己的团队：
每周、每月你最讨厌的那个流程是什么？
如果 AI 能接走那部分机械活，这个流程是不是只剩下“形式意义”？
假如从下个迭代开始不再做这件事，最坏的后果是什么？这个后果是不是可以用其他、更简单的方式兜住？
很有魄力，很有启发。还有几个细节我就不展开了，大家感兴趣自己去看：
1、我们到底还需不需要传统意义上的 iOS/Android 分线组织？
现实情况是：深度专家永远需要，但是否还要维持那种庞大的移动团队结构，值得重想。
2、下一代工程师应该怎么培养？他们进入职场时，可能从来没纯手写过大规模系统。
Fiona 觉得可能要借鉴师徒制，把经验浓缩成更结构化的传授方式，而不是指望每个人通过十年的职业磨砺慢慢悟。
3、每个人都能起几十个 Agent 同时跑，看起来效率爆表，但人类的注意力是有限的。
我们需要一种新的信息护栏和节奏管理，而不是任由自己被通知和任务流淹没。
4、自动化 Review 要推进到什么程度才不失控？
现在的做法，是在高风险区域保留人类专家的终审权，其它地方更多交给自动化和监控。将来怎么平衡安全与速度，她自己也认为是开放问题。
最后和大家推荐下我们 9 月 12 日在上海举办的 AI Maker Summit 大会。
我和团队会请到像今天文章的嘉宾这样有一线实践和思考的同学来分享他们的经验。目前是早鸟价，349 元，很便宜。
这次大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网是：aimakersummit.com
听了 Anthropic Claude Code 和 Co-work 负责人 Fiona Fung 的一期播客，收获不小，解答了不少我内心的困惑。
我在创业，也在经历这个时代的巨大转变。每天仍然会碰到不少难题，比如到底找什么样的人更合适，怎么让自己的小公司更加 AI Native。
这些命题我觉得非常重要，因为我们团队小，所以可以更快。如果团队小又慢又不变化，那基本就死路一条。
这些事情最近一直在想，没有答案。这期播客昨天晚上临睡前点开的，今天早上去公司的路上听完了。我觉得所有做管理的同学都可以看看。
www.youtube.com
前十六分钟信息量不高，基本都在说已经是共识的话题，比如 Anthropic 的工程师每个季度的代码产出是之前的 8 倍，编码已经不是瓶颈了。这些大家都知道。
后半部分我非常喜欢，她回答了比如说这个时代 Anthropic 喜欢招什么样的工程师，她们的团队流程和协作方式是怎么变化的。
非常硬核，有很多细节。感觉所有在做管理的同学都可以读读。
什么样的人开始变得值钱？
其实 Anthropic 内部对于优秀工程师的画像也在变化。这件事说出来稀松平常，但猛地回过头看一下，还是挺震惊的。
也就这一两年时间，行业对于优秀程序员的定义已经迅速发生了变化。
Anthropic 喜欢招两类人。
第一类是有产品感的 Creative Builder。
这部分人能够自己构思产品的体验，做原型，看数据的反馈，然后一轮一轮去调整产品，而不只是像传统的很多工程师那样，只负责实现别人的需求。
我也有这个感受。AI 把能力放大之后，一个人的审美、判断力、主动性，反而变得越来越重要。
如果一个人有直觉、有用户意识，确实就更容易做出来更好的东西。
但这样的人非常不好招。我过去也试图从市场找这类选手，反正还没找到。特别优秀的人，要么去了大公司，要么自己创业了。
第二类是在关键领域有很深功底的工程师。
比如分布式系统、底层性能、安全这些难啃的骨头，他们真的懂。模型再强，这些地方仍然需要人脑加经验来做最终的验证和架构决策。
AI 是把写代码的门槛拉低了，但是深度理解系统、搞清楚依赖和约束、知道哪里应该重构、哪些地方有隐形的风险，这种能力和经验在今天反而更加重要。
其实这两类优秀工程师的画像也是接下来大家的职业发展方向。要么你就是成为一个 Creative 的 Builder，要么就是你在某一方面做得足够深。
另外，抛开具体的工程师类型不谈，Anthropic 面试的时候特别看重 Growth Mindset，也就是成长型思维。这个词过去在互联网圈子也用烂了。
我最近面试也特别在意这一点。一个人如果总是不愿意承认自己不懂，其实挺危险的，因为那就意味着在学习方面的动力也不强。
Anthropic 很看重的成长特质是：
1、愿意承认过去这些年让我成功的那一套，在新世界可能不再适用。
2、面对恐惧，不是本能地抵触，而是问：这件事里有哪些部分在我掌控之内，我可以做什么尝试？
3、主动去拥抱变化，哪怕一开始会觉得不适、甚至要有意做一些让自己害怕的职业选择。
这些话听起来翻来覆去就是成长思维、积极主动。
但我作为一家小公司的负责人，真心觉得有这种品质的人难能可贵。一个人如果能有这样的特质，在 AI 时代应该是能够拿到红利的。
团队之间怎么协同？
我管理公司，最大的一个感受就是不希望有管理。招到好的人，根本不需要管理。
像之前很多公司搞打卡、压 KPI，我觉得那是大公司的管理手段。对于中小公司来说，如果一个人需要通过打卡或者 KPI 去驱动，那可能就不适合在这样的环境里生长。
甚至几年前，我在生气的时候还做过一些错误的决策，比如碰到低级的失误扣奖金之类。现在来回想也是很可笑，这完全就是通过管理手段去管理不合适的人。
这两年我主要的管理思路就是不上管理手段，找到合适的人，大家一起自主地往前推进事情。
听播客的时候发现啊， Anthropic 也是类似的文化，当然人家做的更好。
在 Anthropic，高 Agency 和高 Accountability 是绑定在一起的。
所谓高 Agency，可以理解成，每个人都被当成大人，而不是等指令的小孩。每个人有权自己发现问题、自己立项、自己调动 AI 和资源开干。
但只有高 Agency，没有高 Accountability，团队会演变成一锅粥，大家都很忙、都在搞点啥，团队整体容易跑偏，重复造轮子，也没人真对结果负责。
所以，必须得配套有高 Accountability，也就是清清楚楚的责任感和结果导向。团队每个人要对自己推动的事情负责。
举个例子，一个 Claude Code 团队的工程师，发现用户在某个编辑器场景下频繁抱怨卡顿。
低 Agency 团队里，这个人可能会在 Slack 嘟囔几句，“这个体验好差”，然后等 PM/经理开会排期。
或者在只有高 Agency、低 Accountability 的团队里，他可能会：直接重写一堆逻辑，提个 3k 行的 PR，说我觉得这样更好，然后忙其他的事情去了。
而在 Anthropic 这样的高 Agency 和高 Accountability 团队里，工程师会先下判断，诸如我们在 X 场景下的 P95 latency 比竞品慢 30%，这是用户体感到卡的原因。
紧接着自己起手做方案：让 Claude 帮他分析代码路径，找出最可能的瓶颈，设计一两个能快速上线的优化方案。
在这个过程中，他需要同时给自己、也给团队一个很清楚的责任框架：功的定义是什么？
例如：P95 降到多少、负反馈下降多少。最坏的情况是什么？比如：可能引入某类新 bug，要用什么监控和回滚策略兜底。
在 Anthropic，任务的事情，前面都要有一个简短到可以写在一条 Slack 里的问题陈述和假设。就一句话的模板：
1、我认为问题是 X（数据/反馈证据），
2、假设是 Y（我这么相信的理由），
3、实验方式是 Z（怎么上线、怎么监控）。
这样做的好处是，大家提起新想法的频率会变高，但那种拍脑袋、一时兴起的想法，会因为过不了自己心里的那套 accountability 问题，而在很早很轻的阶段就被筛掉。
关于团队中层的变化
我们团队一直是没有中层的。但最近跟一些在国企或者互联网公司做中层的同学吃饭，大家普遍还是焦虑。
因为有了 AI 后，夹在中间的位置，如果只是做信息转发、进度管理、报表汇总，这个价值会被快速压缩。
我们看下 Anthropic 的做法。
新加入的 Manager，不需要立刻进入管理状态，因为这儿其实管理者又不是让你管人，汇报进度。
所以，Manager 加入之后，会有一个阶段只做一线工作，去写代码、看产品、理解工具链。
即使之后进入管理岗位，也不能完全脱离执行层面。比如要自己写 PR，要参与具体的产品构建。
因为如果一个人不直接参与构建，很快就会失去对问题真实形态的感知。
参与过具体的一线工作，Manager 能很快发现那些 PPT 里不会写的坑。
比如脚本不好用、日志查起来很痛苦、一个小改动要过三道流程等等，也能判断哪些是应该靠流程解决的问题，哪些是其实改两行脚本就没了。
这一点对国内中层其实挺有参考价值。
我们绕不开开会、写汇报没关系，但可以给自己压一条底线。每个迭代，至少有一两件具体的事情，是你亲手推到线上，或者亲手走完全流程的。
只要这条底线守住，你就不会彻底变成一个只会转述别人观点的中转站。
她特别害怕那种口头禅是都挺好的管理层。因为你一旦把没问题当成对上对下的统一口径，组织里的讨论就会自动降维：
下面的人开始习惯性报喜不报忧，问题都藏在走廊、饭局和小群里。直到某个时间点，问题爆成事故，才集体发现原来这么多坑。
所以在一对一里她会主动问最近最不爽的三件事是什么，并且刻意把吐槽当成正常输入，而不是当成负能量。
产品团队的一些变化
她心目中健康的产品团队，大概是这样一种状态：
一方面真心欣赏自己做出来的东西：看到用户用得开心，会觉得“这玩意儿挺酷”。
另一方面被它的各种小问题折磨得想骂人：加载慢、按钮偏一点、复制粘贴不灵，都能让你抓狂。
这两种感受叠加在一起，才会让人有动力每天去微调、去打磨。
如果你只剩下骄傲，觉得我们已经很牛了，那就容易目中无人，不尊重市场。如果只剩下厌烦，觉得自己在给一坨垃圾收拾残局，那大概率也撑不久。
一个健康的产品团队，不应该是看起来一切都很好的状态。有问题很正常。
产品节奏这块，Anthropic 最早他们同样搞过六个月的 roadmap，跟移动互联网时代大家熟悉的那一套几乎一模一样。
先把未来半年想做的大方向写下来，然后按季度、按版本节奏去拆解、执行、迭代。
区别在于，他们很快承认了一个现实，在今天这个节奏下，六个月的 roadmap 基本已经失效了。
模型能力每几周迭代一次，竞品不断试新形态，用户的使用方式被新工具牵着往前跑。
你一份半年计划写完三个月，再回头看，多半已经和真实世界脱节。
所以他们干脆把节奏改成了两个齿轮：
外圈是月度规划：每个月定一次大致方向。本月最重要的几件事是什么。就几条，简单粗暴，大家能背得下来。
内圈是每周快节奏沟通：一周一小结，看这个月那几件最重要的事是不是还成立，需要的话直接微调。
我觉得这里最有启发的是他们在流程上的主动减法。感觉任何一家成立三年以上的公司，都会自然长出一堆流程：
评审、汇报、立项模板、对齐会、跨部门机制……
当年长出来的时候，多半都有合理原因，人多了要防混乱，项目多了要防踩坑。
问题在于，这些流程都是在 AI 还没这么能干的前提下设计的。
AI 来了之后，有些工作本身已经可以自动化甚至直接跳过，但我们沿用的可能已经过时的流程还在。Anthropic 的做法有点简单粗暴，但非常有效：
遇到流程，他们反复追问一个问题，这个东西，现在还在为我们服务吗？还是变成了我们在为它服务？
如果答案偏后者，他们的默认选项是考虑直接砍掉重新设计。
我在想，可以把这套思路类推到自己的团队：
每周、每月你最讨厌的那个流程是什么？
如果 AI 能接走那部分机械活，这个流程是不是只剩下“形式意义”？
假如从下个迭代开始不再做这件事，最坏的后果是什么？这个后果是不是可以用其他、更简单的方式兜住？
很有魄力，很有启发。还有几个细节我就不展开了，大家感兴趣自己去看：
1、我们到底还需不需要传统意义上的 iOS/Android 分线组织？
现实情况是：深度专家永远需要，但是否还要维持那种庞大的移动团队结构，值得重想。
2、下一代工程师应该怎么培养？他们进入职场时，可能从来没纯手写过大规模系统。
Fiona 觉得可能要借鉴师徒制，把经验浓缩成更结构化的传授方式，而不是指望每个人通过十年的职业磨砺慢慢悟。
3、每个人都能起几十个 Agent 同时跑，看起来效率爆表，但人类的注意力是有限的。
我们需要一种新的信息护栏和节奏管理，而不是任由自己被通知和任务流淹没。
4、自动化 Review 要推进到什么程度才不失控？
现在的做法，是在高风险区域保留人类专家的终审权，其它地方更多交给自动化和监控。将来怎么平衡安全与速度，她自己也认为是开放问题。
最后和大家推荐下我们 9 月 12 日在上海举办的 AI Maker Summit 大会。
我和团队会请到像今天文章的嘉宾这样有一线实践和思考的同学来分享他们的经验。目前是早鸟价，349 元，很便宜。
这次大会一共设计了八个专题，包括：
AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。
四个分会场并行，一天时间，36 个 talk。
我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。
可能跟其他大会不太一样，我们不看 title，不看年龄。重要的是看嘉宾在用 AI 做什么，解决什么问题。
所以，这个大会上，大家能看到的一定都是最新鲜的思考和实践。
大会官网是：aimakersummit.com
0 00
深圳这几场 AI 分享，我自己也很想听
距离 AI Maker Summit 深圳站开幕，不到一周了。
昨天把伴手礼也确认了。和团队精挑细选了一个思考的小摆件，希望大家能喜欢。
我认为，在 AI 能力越来越强的今天，也许最重要的事就是我们不能把思考让渡给 AI。
马斯克说，2026 年是近两百年来最重要的年份之一。
能在这样的年份里组织这样一场大会，特别兴奋，特别有成就感。虽然这事并没什么利润，但做一件有意义的事情，不也挺好？
深圳站涵盖的内容很多，有热点，也有 AI 领域必须关注的议题。到今天，所有话题已经全部确认。嘉宾这边我可以打保票，他们都带着新鲜的实践和洞见来的。
一天时间，四个会场。希望这些内容能给大家带来启发。
日程安排：aimakersummit.com
也许往后某一天，会有人想起来，多少年前在 AI Maker Summit 深圳站听到过谁的一个观点，后来激发了他去创业，去做点什么。如果真有那一天，我也与有荣焉。
还是老规矩，日程确定之后，下周折扣期就结束，进入最后一程。
深圳见。aimakersummit.com
距离 AI Maker Summit 深圳站开幕，不到一周了。
昨天把伴手礼也确认了。和团队精挑细选了一个思考的小摆件，希望大家能喜欢。
我认为，在 AI 能力越来越强的今天，也许最重要的事就是我们不能把思考让渡给 AI。
马斯克说，2026 年是近两百年来最重要的年份之一。
能在这样的年份里组织这样一场大会，特别兴奋，特别有成就感。虽然这事并没什么利润，但做一件有意义的事情，不也挺好？
深圳站涵盖的内容很多，有热点，也有 AI 领域必须关注的议题。到今天，所有话题已经全部确认。嘉宾这边我可以打保票，他们都带着新鲜的实践和洞见来的。
一天时间，四个会场。希望这些内容能给大家带来启发。
日程安排：aimakersummit.com
也许往后某一天，会有人想起来，多少年前在 AI Maker Summit 深圳站听到过谁的一个观点，后来激发了他去创业，去做点什么。如果真有那一天，我也与有荣焉。
还是老规矩，日程确定之后，下周折扣期就结束，进入最后一程。
深圳见。aimakersummit.com
0 00
AI Maker Summit 大会日程上线了，讲师演讲内容陆续确认中。
5 月 23 日，周六，欢迎大家来现场交流。一起看看别人的最新思考、真实实战和独立判断。
大会日程：aimakersummit.com
大会官网：aimakersummit.com
5 月 23 日，周六，欢迎大家来现场交流。一起看看别人的最新思考、真实实战和独立判断。
大会日程：aimakersummit.com
大会官网：aimakersummit.com
0 00