agentteams用什么模型

真心建议大家花三点五小时练完这一百六十八页，你的 agent 搭建就很牛了。其实很早之前就想搭建一个自己的 agent 了，不过一直没时间。趁着春节有空，我终于从零上手搭建了一个 agent 智能体。我搭建的时候顺带把整个流程录制成了视频教程，搭配一百六十八页教程文档 视频教程以及代码文档都可以给到大家，带你从零开始搞懂什么是 agent， 再到 agent 的 搭建实战， 里面的内容都是针对新手的，小白也能看懂，不管你是零基础小白还是有经验的学习者，都能轻松上手。视频以及文档我都已经打包好了，想自己动手搭 agent 智能体的宝字留下学习双手奉上。

哎，我今天呀，很开心，但是又很沮丧，开心的是一堆模型更新了， glm 五啊， mini max， 二点五我都用上了，但是沮丧的是，我在搞钱的路上又受挫了。 我前面视频里说过，我们应当用 ai 做杠杆，跑通一个小闭环，然后再找到更多的闭环，你不管能不能搞到钱，至少能大幅提升效率，对不对？当我们找到了一个场景，我们就要用掉 token 额度转换成解决方案。 token 大家知道吧，可以对比为手机流量就是 ai 的 燃料。现在大部分场景都是提效类的，比如说一件事，加速了十倍、一百倍，它自然产生价值。假设我们的 token 能产生价值，那接下来就只有一个问题了，你要怎么样大量消耗 token？ 我 之前分享过， 在这个 ai 时代，规则还不清晰的时候，谁有能力烧掉更多的 token， 谁就更容易有机会赚到钱。烧 token 能解决很多事啊，比如说获取信息啊，加工信息啊，做工具链，产出内容什么，这太多了，但是你以为你想烧 token， 你 就能烧的掉吗？ 比如说我用主流的 ai 工具 cloud code 来举例，一个窗口只能解决一件事，而且要花很多时间。这个大家都知道， 如果你尝试过同时开多个窗口去工作，你会发现这是一件极其消耗心智的事，你自己的大脑的上下文啊，会反复的切换，非常痛苦，这和工作的心流没有一点关系。我前几天一直在说 agent teams， 好 多人都说他烧托克， 但是实际上 agent teams 就是 解决这事的。比如说我啊，我现在有好几家的最高档的 coding plan， 还有本地的算力，这些用量我根本就消耗不掉，因为我菜啊，我玩不了那么多窗口。但是有了 agent teams 就 不一样了， ai 小 组是自组织的，它一个任务可以跑很久，一个小时，两个小时，而且完全不用你来监管，这样我们就只需要想好任务，扔到队列里等着就是了。 昨晚 glm 五发布的时候，我就很兴奋，所以我就一直在尝试把我的一些工具链的开发任务交给他。这个模型真的很强大，输出质量相当好。 举个例子，我有个任务，就给我的 ppt 开发出一些更具视觉效果的，更具动态的小插件。因为大家都知道我的视频都是 ppt 录屏，但是因为它都是静止画面，现在平台有什么光流算法呀，静态检测呀，这些画面静态的太多，就会导致我权重很低。 我让 glm 五做了很多插件，效果都还不错。于是啊，我就尝试让他开个小队去做集体 review， 分 析他已经做好的这些插件，看看能不能通过勇于计算，通过集体的这种智慧碰撞，找到一些问题。但是经过一番尝试啊，我发现这事有问题。 不光是 glm， 其他的国产模型也是一样的，他们都完全没有对 a 阵的蜂群的协助做训练， agent teams 里面的工具链他们都不会用，或者说他们不知道什么时机该用这些工具，什么时机该沟通，什么时机要等待。而且主控的 leader 就 更离谱了，他完全不懂编排。他启动了一个开发，启动了一个测试，一个审查者，让他们去开会，去讨论， 结果程序员上手直接就改代码，测试员上来就直接启动服务器开测，只有审查者一个人在那审查，审查完了还没通知，导致 leader 呢，一直在轮询，最后 leader 等不及了，自己上手就开始改代码了。哎，这场景好像还挺熟悉的是吧， 我觉得啊，如果看我视频之后就跑去尝试国产模型和 agent teams 的 这些朋友肯定都会抓狂。但是这其实不是问题，也不是这个事让我沮丧的，反而体现出我之前提过的这个编排有多重要。我给大家教一个技巧啊， 就你的模型，如果不会启动 agent teams， 或者不会调用里面的工具，你就找个更好的能使用 agent team 的 模型，让他们来分析系统内置的 agent teams 的 功能，以及 mailbox 如何用啊，参数是什么样的之类。 因为这些都在他的上下文里头，他回答好之后，你用一个 skill creator 做成一个 slash teams 技能，这样就完全弥补了模型找不到知识的问题。这个技巧啊，尤其是对这种八十币啊三十币的小模型非常有效。但是我发现还不够， 他们其实还缺少策略。于是我就问 ai 描述我的痛苦，我的痛点是什么？比如说审查阶段，程序员直接就开干了，这怎么办？ ai 就 会给我提方案， 我让它就直接写入 teams 这个技能的规则里。所以最终我产生了三个文件， skill 点 md， 描述工具的细节，对不同任务的分工方式以及角色配置。还有一个 role 点 md， 用来预定一些角色 protocol 点 md， 主要是描述了角色之间的协作规则， 比如说什么时候用 mailbox， mailbox 应该只做通知，但带上文件链接等，那什么时候应该广播，什么时候应该私聊，也写到这个规则里头。 经过我的一番努力，这个 skill 终于让各个模型对 agent teams 的 使用发生了质的变化， 团队开始变得像我预期那样开始写作了。哇，那一刹那，我真的太兴奋了，我就好像发现了打开宝库的秘密，我甚至想着会不会像以前打网游的时候那样 多开挂机，然后早上起来收菜那种感觉。但是结果呢，是让人沮丧的。虽然讨论的过程啊，大家都充分合作，发现了大量的 bug， 但是因为我想测他们的能力嘛，所以我没有给他描述具体的问题，而是让他们尝试去发现。 结果就是没有一个 agent 发现了我希望他们发现的问题。而在测试阶段，因为它 glm 视觉受限，它不是一个多模态测试者，也没能发现样式和动画的问题。我们人类在解决这些困难的时候，也会遇到各种各样的问题，但是我们会通过反思啊， 质疑假设，多角度审视来发现问题，发现解决问题的路径。尤其是你在一个团队里头，集体的目标还会激励你，鞭策你，还有团队成员跟你提供帮助。但是现在的 ai 就 完全还没有这种基因呢。 最后，这个问题还得是通过古法人工介入，录了个屏发给 kimi， k 二点五多模态就轻松解决了。 这件事虽然让我沮丧，但是我也是有收获的。我发现一个道理啊， agent teams 这种自组织更适合解决那种发散型的任务，而不是收敛式 的。比如说我让 ai 去开个讨论会，分析现在已有的插件，然后再让他发明几个新插件。哎，这个任务他们就做得很好。再比如说分析我的稿子，分两方面论，给我产生灵感，这些效果都非常好。 我用这种方法得到了很丰富的创意，因为这类任务本质上是 test time skilling， 通过多采样增加可能性。十个 agent 各享十个方案，你不就有一百个方案了吗？ 这种任务肯定能成功，但让他们收敛就难了。你让群体智慧去验证解决方案，挑出那个最好的， 特别容易流入形式化。大家表面上在讨论，实际上是在各自重复已有的观点。我看到 kimi c l i 的 ripper 上，有人提到过一个概念，叫上下文商。 当多个 agent 并行 review 同一份文稿的时候，他们就会产生大量的噪声信息。每个 agent 都在输出，都在贡献内容，但信息增益却是递减的。这不是模型能力的问题，这是并行架构本身存在的问题。并行适合发散， 不适合收敛，这个区分很重要。如果你要 ai 帮你发散创意，头脑风暴， agent teams 非常适合，但是你要让 ai 帮你拍板决策、质量检查，目前我觉得还得靠工具，还得靠人。 当然，这次探索也是有收获的。第一就是 agent teams 可以 通过编排被控制，你定义好 skill role portal， 本身很 chaos 的 agent 也能按预期写作。 第二就是多样化，你得靠蜂群，但是收敛你得靠系统。自组织是必然产生浪费的。一百个 agent 能产生出一百种方案，但其中九十个方案都是伤，所以我们需要收敛系统来排除这些伤。 自动测试啊，录屏验证啊，指标评分都是很好的收敛系统，而且我们需要在系统无法判断正确与否的时候让人为的介入。 你需要定义什么叫失败，并且让 agent 学会喊人。最后啊，探索还是很有乐趣的，我也依然保持乐观。二零二六年的主线依然是编排， 编排就是定义从混沌到秩序的商碱过程。大家等我更新吧，看我怎么继续折腾。好了，以上就是本期全部内容，谢谢大家！

今天教你如何使用 opcode 切换两个大模型，一个是 glm 四点七，一个是国产的千万大模型， opcode 提供的模型供应商有这些，你可以选择你需要的大模型进行切换。首先打开终端，输入这行指令， 可以看到我当前的大模型是 glm 四点七。最下面是让你选择是本地部署还是远程部署，我这里选择本地部署。 紧接着就是让你选择配置的区域，这里选择模型配置。再接下来就是进入到了模型列表界面，这也提供了很多的模型供应商， 因为我已经配置了 g m 四点七，所以我这里选择千问来进行配置。每一个模型后面都有写是进行授权登录，还是说通过年提 api 进行登录。 我们选中千问后回车，然后确认一下，会弹出一个浏览器的网页，我们点击一下授权的确认按钮， 认证成功后就可以回到命令行界面进行下一步的操作。在这个模型列表一页，他默认其实已经把纤维模型给选中了，我们可以往下滑找到纤维模型，确认一下是不是选中状态，也可以直接按回车进行到下一步。我这里已经看到纤维模型已经被选中了，我直接回车进行到下一步。 这个时候千万模型其实已经配置好了，我们点击键盘上的 esc 退出界面，然后再重新输入刚才的命令，确认一下是不是当前模型变成了千万模型。 我们输入键盘的 esc 退出后输入这个命令，打开浏览器界面，我们点击右下角的按钮，创建一个新的绘画，然后输入一个问题，你是哪个大模型？他的回复是同意千万模型。到此，整个切换模型的步骤就完成了，接下来我要切回到 g l m 四点七， 然后演示一下如何黏贴 api k。 前面步骤和刚才的千万大模型都是一样的，只不过是模型授权的方式不一样， 刚才是通过浏览器登录授权，现在是需要去对应的模型官方获取 api k 之后粘贴进来，选择 glm 四，点击这个模型之后，回车之后它会提示我要去黏贴 api k， 一 般都是登录官网找到 api k 管理页面，然后黏贴一下 api k， 身后的步骤和刚才千万模型的配置一样，我们直接回车就配置完成了。输入这个命令之后，我们可以看到当前的模型已经变成了 g l m 四点七。入这个命令之后，我们打开浏览器网页，在绘画窗口输入你是哪个大模型， 这个时候已经切换到 g l m 四点七了，整个过程就是这样，有需要的小伙伴快去试一试吧，这里是 ai 共生格，我们下期见。

这篇教程的目标是不花一分钱用一部安卓旧手机把 openclaw 跑起来，全程不需要电脑模型，使用 nvidia 免费的 mini max m 二点一。 第一样东西是旧手机，并且要恢复出厂设置，因为这台手机会变成小型服务器，先做数据隔离更安全。 第二样是模型 a p i t。 教程推荐 nvidia 免费模型，在 build 点 nvidia 点 com models 注册后选择 mini max m 二点一，并创建 a p i t。 第三样是非输机器人应用，先创建企业自建应用，保存 f i d 和 app secret， 开启机器人并导入权限事件订阅要选长连接并添加，按 message receive 下划线。 v 一， 正式部署时，先安装 termax， 然后执行更新升级，再安装 node、 python、 git 和 port。 这里 port 是 后面 termax port 的 依赖，必须提前安装。 接着安装 openclaw， 命令是 mpm install gopenclaw at latest， 安装时间通常十五到二十五分钟。完成后执行 openclaw help， 看到帮助信息就说明安装成功。 最关键的是 step 六，顺序不能反，先 terminates crate， 再 open cloud on board 驶驶划时渠道选发射 skills 选 yes， 其他 a p i 绑定都先选 no。 如果 on board 理菲书插件安装失败，常见原因是 dev dependencies 里有 workspace 协议，按文档删除那一段，再重新 npm install 就 可以。 on board 完成后执行 opencloud channels app， 选择发射并输入前面保存的 app id 和 app secret。 step 七，先做备份，再改配置。先复制一份 opencloud jsn 作为回滚文件，然后用 nano 打开原文件，后面只改三个位置，其他字段都不动。 step 七，第二步，先改默认模型，定位到 agent's default model， 把 primary 改成 nvidia slash， mini maxi， slash， mini max and 二 point 一 step 七第三步，在 models providers 里新增 nvidia base url， 按文档填 a p i t， 换成你自己的密钥。 models 里保留 mini maxi， slash， mini max and 二 point 一 step 七最后一步，确认飞书插件已起用，检查 plugins entries 里的飞书 enabled 必须是 true。 保存退出后再启动 gateway。 step 八，启动 gateway， 看到 opencloud gateway error 不 用慌，按教程执行 opencloud gateway verbooth 日制正常连续输出就代表服务已经起来了。 防掉线设置，先做微 clock， 按原文步骤下拉通知栏，点击 termox 通知里的 acquire 微 clock， 然后再关闭电池优化，进入手机设置，找到 termox 开启允许后台高耗电，或者设置为不进行电池优化。 手机部署有局限，比如性能和响应速度不如电脑，部分高级功能可能不可用，而且长时间运行会发热，但用于日常聊天和入门体验已经足够。

你在用 cloud code 做一个大项目的时候，是不是经常觉得一个 session 不 够用？ 改前端的时候，后端在 id 写测试的时候，主逻辑停了， review 代码的时候，只能从一个角度看，你想让 cloud 同时干好几件事，但一个 session 只有一个脑子干完一个才能干下一个。现在 cloud code 支持了 agent teams， 你 可以同时跑多个 cloud 的 实力，让它们像一个真正的开发团队一样写作。今天这期视频看完，你就能在自己的项目中把 agent teams 用起来了。 大家好，这里是 l l m x factors， 一个专注于拆解大语言模型时代底层逻辑的频道。 今天我会从四个层面帮你完整理解 agent teams。 首先是它到底是什么，我会用一张架构图帮你建立全景认知。然后是核心机制，从起用配置到任务系统到通信方式六个步骤逐一拆解。 接着是三个实战场景，并行 code review、 竞争假设、 debug 以及跨层并行开发。最后是决策框架，帮你判断什么时候该用 agent teams， 什么时候用 subteams 或者 denunciation 就 够了。 好，既然知道了为什么需要它？我们来看看 agent teams 到底是什么？我先给你一张全景图。 agent teams 的 整体架构有四个核心组建我一个一个讲。最上面的 team lead 就是 你当前的 cloud code session， 它的职责是创建团队， 给每个 teammate 分 配任务，最后综合所有人的工作结果，你可以理解成项目经理。下面这些是 team mates， 每个都是一个独立的 cloud code， 实力关键词是独立。每个 team mate 有 自己的 context window， 互相之间不共享上下文，这意味着 team mate a 不知道 team mate b 在 做什么， 除非通过消息系统沟通，然后是两个共享资源。 tasklist 是 所有人都能看到的任务看板 lid 在 上面创建任务， teammates 可以 认领和更新状态。 mailbox 是 消息系统，支持两种模式，点对点发给特定 teammate 或者广播给所有人。 打个类比帮你理解。 agent teams 就 像一个项目经理带几个工程师 pm 在 giro 上创建 ticket， 工程师认领后在 slack 里沟通， team lead 就是 pm， task list 就是 giro， mailbox 就是 slack， 每个 teammate 就是 一个工程师。但这个类比有一个重要区别， 真实的人类团队，工程师可以走到对方工位看代码，或者共享同一个知识库。 agent teams 不 行，每个 team mate 有 自己独立的大脑，也就是独立的 context window， 不 能直接看到其他人在做什么， 所有信息交换都必须通过 mailbox 显示通信。这个区别很重要。后面讲到最佳实践的时候会用到 很多人会把 agent teams 和 subteams 搞混，我们来看看它们的核心区别。从 context 来说， subteams 是 在主 agent 的 session 内运行的，结果返回到主 agent 的 context 里，而 agent teams 的 每个 teammate 有 完全独立的 context window。 通信方式上， subservants 只能向主 agent 汇报，最终结果是上下级关系。 agent teams 的 kinmates 可以 直接互相发消息，是平级协助关系。任务协调方面， subservants 有 主 agent 全权管理， agent teams 有 共享的 task list， team mates 可以 自己认领任务，不用等力的一个一个分配。适用场景上， sub agents 适合聚焦型任务，你只需要最终结果。 agent teams 适合探索型任务，需要团队成员之间的讨论和挑战。最后是成本， agent teams， 因为每个 team mate 都是独立实力， token 消耗会明显更高。一句话总结， sub agents 是 派出去办事，然后汇报。 agent teams 是 组建一个真正的协助团队， 给你一个快速判断逻辑。你的任务需要多个沃克同时工作吗？如果是下一个问题，这些沃克之间需要互相沟通吗？如果不需要，每个人独立完成任务，然后汇报结果就够了， 那用 subordinates， 清亮又慎重肯。如果需要，比如一个人发现了什么，要告诉另一个人，或者需要互相挑战对方的方案，那就用 agent teams。 还有一种情况是任务之间有依赖关系。 agent teams 的 task list 原生支持依赖管理 任务 a 没完成任务 b 就 不会被认领。 sub agents 做不到这种级别的协调。记住这个判断标准，需要沟通。用 teams 不 需要沟通，用 sub agents 有 复杂依赖也优先考虑 teams 概念清楚了，我们来拆解 agent teams 的 核心机制，一共六个步骤，先减后烦，一步一步来。 第一步，奇用功能， agent teams 目前是实验性功能，默认关闭。你需要在 settings 权限里加一个环境变量，把 cloud code experimental agent teams 设成一这个文件在你的后目录下的 cloud 文件夹里。同时你可以设置显示模式。 teammate mode 有 三个选项， auto 是 自动检测， in process 是 所有 team mate 跑在主终端里， timax 是 每个 team mate 一个独立的终端分屏。 auto 模式下，如果你已经在 timax 里，就自动用分屏，否则用 in process。 建议刚开始用 in process 最简单，不需要额外安装任何东西。 第二步，创建团队你不需要写任何配置文件或调用 a p i， 直接用自然语言告诉 crotd 你 想要什么样的团队，多少个成员，每个人负责什么。比如你说帮我创建一个团队来 review p i， 一 百四十二三个人分别看安全、性能和测试覆盖。 crotd 会自动创建团队 深沉共享的 task list spawn， 三个 teammate 给每个人分配对应的任务。你还可以指定具体用什么模型，比如让每个 teammate 都用 sonnet cloud 也可能主动建议创建团队，如果他判断你的任务是合并型处理，他会问你要不要组团，但最终决定权在你， cloud 不 会未经确认就创建团队。 第三步，理解任务系统。 tasklist 是 agent teams 的 核心协调机制。每个任务有三个状态， pending， in progress， completed。 流程是这样的， lead 创建任务后，状态是 pending teammate， 认领任务后，状态变成 in progress。 工作完成后， teammate 把状态改成 completed。 lead 有 两种方式分配任务，一种是显示分配，直接告诉某个 teammate 去做某个任务。另一种是让 teammates 自己认领，完成一个任务后自动去 tasklist 上找下一个没人做的任务。 这里有个细节，任务认领用了文件所机制，防止多个 teammate 同时抢同一个任务。 任务系统还支持依赖关系，比如测试任务依赖于功能实现，任务实现没完成，测试就不能开始。 你可以在创建任务时声明依赖系统会自动管理。当一个任务被标记 completed 后，依赖它的任务会自动解锁，变成可认领状态。 这个设计很重要，它保证了有先后顺序的工作，不会乱套，同时不需要人工去盯着解锁力的，只需要在创建任务时把依赖关系说清楚，后面的调度全是自动的。 到这里，你已经知道怎么起用 agent teams 怎么创建团队以及任务系统是怎么运作的了。 回顾一下，起用只需要在 settings justin 里加一行环境变量，创建团队用自然语言描述就行。任务系统有三个状态支持依赖管理， team mates 可以 自己认领任务， 这三步是基础，掌握了就能跑起来了。接下来是更有意思的部分， team mate 之间怎么沟通，以及几个让你精细控制团队的高级功能。 第四步，通信机制。 teammates 之间通过 mailbox 通信，有两种模式，第一种是 message 点对点发送，你给特定的某个 teammate 发消息，只有他能收到。适合针对性的协调，比如 lead 通知，安全 reviewer， 重点关注某个文件。第二种是 broadcast 广播，一条消息同时发给所有 teammates， 适合全员通知。 比如某个 teammate 发现了一个关键 bug， 需要所有人都知道，但要注意广播的成本，每个 teammate 都会把这条消息写入自己的 context window， 所以 广播用得越多， token 消耗越大。还有一个设计细节， 消息到达后是自动投递的 le 的， 不需要主动轮询， teammate 完成任务后也会自动通知 le 的。 第五步，显示模式。 agent teams 支持两种显示方式， in process 模式，所有 teammates 跑在你的主终端里，用 shift 加上下箭头切换不同的 teammate， 按 enter 查看某个 teammate 的 完整输出， 按 escape 可以 打断它当前的工作。这个模式不需要任何额外安装，任何终端都能用 splitpence 模式，每个 teammate 有 自己独立的终端分屏，你可以同时看到所有人在做什么，点击某个面板就能直接和那个 teammate 对 话， 但这个模式需要 tmax 或者 itm。 二、我的建议是先用 in process 入门，等你熟悉了 agent teams 的 工作方式之后，再切到 splitpence， 获得更好的个性化体验。 第六步，高级控制这里讲三个重要功能。第一个是 delegate mode， 默认情况下， lead 有 时候会忍不住自己动手写代码，而不是等 team mates 完成。你可能已经分配好了任务，结果 lead 自己先做了一半，搞得和 teammate 的 工作重复甚至冲突。 delegate mode 解决这个问题，它限制力的只能做协调工作。 spawn teammate 发消息管理任务，不允许直接修改文件或写代码，所有实际的代码修改都必须交给 teammates， 按 shift 加 tab 就 能激活。这个模式在任务比较复杂， teammates 比较多的时候特别有用。 你希望 lead 专注于总控和综合，而不是分心去做执行。第二个高级功能是计划审批。对于复杂或有风险的任务，你可以要求 teammate 先做计划再实现。 具体流程是， lead 在 spawn teammate 的 时候声明需要 plan approval， teammate 会进入止读模式，只分析问题和制定方案， 不做任何修改。方案完成后提交给力的审批，力的可以通过，也可以拒绝。如果拒绝了，会附上反馈 teammate， 根据反馈修改计划重新提交。只有审批通过后， teammate 才能退出计划模式，开始实际编码。 你还可以给力的设定审批标准，比如只批准包含测试覆盖的方案，或者拒绝修改数据库 schema 的 方案。 第三个是 hooks， 可以 理解成质量文 code code 的 hooks 系统支持两个和 agent teams 相关的钩子， teammate idol。 当一个 teammate 即将进入空闲状态时出发，如果你的 hook 脚本返回 exit code 二，就会把反馈发给 teammate， 让他继续工作，而不是停下来。 task completed， 当一个任务即将被标记完成时，触发同样， exit code 二可以阻止任务完成并发送反馈要求改进。这样你就可以用自动化脚本来做质量检查，比如跑一遍 link， 跑一遍测试不通过就不让 tmit 收工， 机制都清楚了。接下来我给你三个真实的使用场景，让你看到 agent teams 在 实际项目中怎么用。 第一个场景并行 cold review， 传统的 cold review 一个人看往往会偏向某一类问题，比如你可能先看到了安全问题，然后就一直在安全的角度上深挖性能问题，就容易漏掉。用 agent teams， 你 可以同时 spawn 三个 reviewer， 一个专看安全，一个专看性能，一个专看测试覆盖。每个 reviewer 只关注自己的维度，不会互相干扰。看完之后，力的综合三份报告，给你一个全面的 review 结果，这比一个人创新 review 三遍要高效得多。 而且因为每个 reviewer 是 独立的 context， 不 会因为先看了安全问题就对性能问题产生认知偏见。 第二个场景，竞争假设 debug， 这是 agent teams 最有趣的用法。当一个 bug 的 根音不明确时，一个人调试容易陷入铆钉效应，找到一个看起来合理的解释就停了， 其实可能不是真正的原应用 agent teams， 你 可以 spawn 五个 teammate， 每个人负责验证一个不同的假设。关键是这里用了一个对抗式设计。 每个 team mate 不 只是验证自己的理论，还要试图推翻其他人的理论，就像科学辩论一样，最终经受住所有挑战的假设，才更可能是真正的更硬。 这个 prompt 里有一个细节很重要，让他们互相 talk， 互相 disprove， 这正是 agn team's 比 sub agn 强的地方。 sub agn 做不到这种横向讨论。 第三个场景，跨层并行开发。比如你要做一个新功能，涉及前端组建，后端 a p r 和测试。传统做法是串行，先写后端，再写前端，最后写测试。用 agent teams， 你 可以三个 team mate 并行， 一个负责前端，一个负责后端，一个负责测试， lead 负责协调，比如确保前后端的接口齐员一致。当后端 team mate 修改了 api 的 参数格式，它可以通过 mailbox 同之前端 team mate 同步调整。 这里有个重要原则，三个 team mate 要操作不同的文件，如果两个人同时改同一个文件，会导致覆盖冲突，所以在分工的时候要把文件边界划清楚。 场景看完了，最后帮你做一个决策框架，什么时候选 agent teams， 什么时候不需要，先看，什么时候适合研究和 review 任务。多个 team mate 可以 同时从不同角度调查同一个问题。 比如刚才说的并行 code review 新模块开发，每个 team mate 负责一个独立的模块，互不干扰竞争假设 debug 并行测试，多个假设用对抗式辩论收敛。 跨层修改，前端后端测试各一个人，再看什么时候不适合。顺序依赖的任务，后一步必须等前一步完成。并行没有意义。同文件编辑，两个 teammate 改同一个文件会互相覆盖。 简单，任务协调本身就有开销，任务太小的话开销大于收益。 token 敏感的场景， agent teams 的 token 消耗是倍数级的。核心判断标准就一个，你的任务能不能拆成独立的并行单元，能拆就适合，不能拆就不适合。 aging teams 目前还是实验性功能，有一些限制，要了解。第一，不支持 session 恢复。如果你 resume 一个 session 之前的 in process， teammates 不 会恢复， lead 可能会尝试给不存在的 teammate 发消息，这时候你需要告诉他重新 sport。 第二，一个 session 只能管一个厅，想建新团队必须先清理旧的。第三，不能欠套。 teammates 不 能创建自己的子团队，只有力的能管理团队。第四，力的固定，谁创建的团队谁就是力的，不能转让。 第五，任务状态有时会滞后， timet 可能忘了把任务标记成 completed， 导致依赖他的任务一直堵塞，遇到这种情况手动提醒一下就好。第六， splitpence 模式需要 tux 或 iterm。 二 vs code 集成终端和 windows terminal 目前不支持。 最后，给你一个最佳实践速查表。第一，给 timet 足够的上下文， timet 不 继承立德的对话历史， 所以 spawn 的 时候要在 prompt 里把项目背景、文件路径、技术栈关注重点都写清楚。第二，合理拆分任务力度。太小的任务协调开销大于收益，太大的任务， teammate 可能跑偏了你都不知道。 经验值是每个 teammate 分 配五到六个任务，既保证持续生产力，也给力的足够的机会调整方向。第三，避免文件冲突。两个 teammate 改同一个文件会覆盖， 所以分工的时候一定要把文件边界划清楚。第四，定期检查进度，不要让团队 unattended 跑太久。第五，如果你是第一次用，从 review 和 research 类任务开始，这类任务边界清晰，风险低，是最好的练手场景。 我们来回顾一下今天的内容。 agent teams 由四个组建构成， team lead 负责协调。 team mates 独立执行 task list， 管理任务状态和依赖。 mailbox 提供点对点和广播通行。它的核心价值是并行探索和多角度协助，特别是 teammates 之间可以互相挑战对方的方案。 和 substance 相比，如果你的 walker 之间需要沟通，就用 teams， 只需要最终结果就用 substance。 最适合的场景是 code review 竞争，假设 debug 和跨层并行开发， 使用时注意避免文件冲突，保持合理的任务力度。给 teammates 足够的上下文，如果你想试试的话，建议从你下一个 pr 的 code review 开始。 spawn 三个 reviewer 分 别看安全性能和测试，感受一下并行 review 的 效果。 如果这期视频对你有帮助，记得点个关注，这里是 l l m x factor， 我 们下期见。

大家好， cloud 在 发布这个 open 四点六的时候， cloud code 也有一个新的功能，叫 cloud agents teams， 就是 你可以自己开启一个这样的团队去开发功能。那本期视频呢？将从四个方面来介绍一下 agent teams 是 什么， 然后我也结合了一个网页，里面有一些动画特效，来给大家详细的讲解一下 agent teams 和 sub agents 的 区别是什么。因为这两个问题就是什么是 cloud agent teams。 在了解这个 claw 的 teams 之前，我们来看一下整个我们跟 claw 的 进行对话，或者说跟类似的 a 技能对话的一个发展的历程。 那么一开始的时候，当你启动一个这样的 claw 的 实力，那说明对话的时候只有你和这个 claw 的 主主 agent， 我 们把它标志成叫主 agent， 主代理，那这个阶段叫做啊，我们叫做主代理进行对话，那这个阶段叫做独行侠时代，就是只有你和主代理进行一对一的对话， 那这个总对话方式优点就是简单，你说什么他就做什么，大家都是创新的去执行，就是你发布任务执行完成，你看结果，然后再接着发布第二个任务。 那这样的缺点是什么？就是你的上下文窗口有限，就是上下文很容易就被塞满了，比如说你现在要让他进行一个 p r d 文档的书写， 那么生成的这个 prd 文档可能有一万个字，那这一万个字就会占用你跟它对话的这个上下文，那就会触犯压缩，而且你每一次只能做一件事情，对吧？写 prd 文档的时候写 prd 文档，写代码的时候写代码，那为了解决这个三个问题呢？ 那就进入了我们的这个 safari 子代这个时代，那子代的时代就是你的有些事情可以分配给其他的这种代理去执行。比如说我刚刚说到的 写 prd 文档，那么你可以有一个叫产品经理的子代理，你发给他，让他去创建这样的 prd 文档，那么他创建 prd 文档生存那一万个字，他是不会在跟跟你的主对话，跟你的主代理之间是不会影响的，不会影响的， 我们假设一下，你跟主代理之间进行了十次对话，产生一百个字，这个时候你需要去创建一个文产产品说明文档，这个时候如果你发给这个 产品经理，让他去创建了吗？产品经理创建了一个一万次的这个文档，他创建完成之后，他自己的上下文就销毁了，然后你这边的上下文还是那十轮对话的上下文， 如果不使用这种子代理，那么你就会把这个 p r d 的 这个整个生成过程产生的上下文塞到这个主对话里面去。所以呢子代理 的出现就解决了这么个非常大的问题，就是断线纹隔离，而且他能并行执行。你在写代码的时候边写边测试，那么你可以设置一个写代码的主代理，主代理就是你写代码，然后子代理去测试你的代码，那这样的话就并行执行，然后还选能选择不同的模型， 对吧？你测试可能是你要求没那么高，要求快速的，那么你会选择一个这种 flash 啊，或者其他的这种型号的模型。但是这种子代理也有什么问题呢？就是每一个 agent 子 agent 之间是不不能沟通，不能交流的， 大家都是独立完成任务，然后告诉一个这样的摘药，给到我，给到你，然后你其实你如果你需要完成的是一系列的任务，比如说你现在做一个从零到一，做一个产品，那这里面涉及到 prd 文档，涉及到前端代码，后端代码， 对吧？测试，那大家其实都是围绕怎么从零到一完成这个产品这一系列的任务来的， 那这个时候你可以想象一下，在一个公司里面，如果你要做一个产品，那么肯定是一个协助的过程， 那前端开发，开发完之后如果有什么问题需要跟后端去对接去沟通，那后端弄完之后可能要找测试去测试，那需每一个人之间是有沟通的。所以呢， it 的 teams 就是 拥有了这些 teams 的 这个优点， 它除了有 sub agents 的 这个特点之外，它又新增了个，新增了些，每一个这样的子代理 agent 之间都是可以发消息来沟通的，那有一个 team leader 来负责整个的这个协调， 整个队伍的这个任务分配协调啊，这个消息的发送啊，或者其他的这种东西，它有一个总的这样的一个去管理，就跟我们真实的团队是一样的，那 这种就做到了真正的就像一个很强大的一个这样有效的这种工作运行的工作方式。所以呢， teams 比这个 subteams 又进行了一个升级。 那我们再往下看，就是用一个公司来比喻理解的话，那普通模式就是你只有你一个人，只有你一个人，你一个人能力是有限的，你只能创建去执行，按顺序执行这个任务。 那纸质问题就是你是一个老板，你派人去帮你查资料，审代码，那么你关注的是这个结果， 你关注的是结果，而且他们各自的这个做的这些事情是没有任何联系的，是断开的。查资料是查资料， 省大脑，省大脑，这两之间是没有任何关联关系的，是不存在，他们需要沟通，不需要去协助，非常独立，所以他们能有拥有独立的上下文，能够干完这个事情就把上下文销毁掉，会影响那 tips， 就是 这些人需要去沟通，去共享或整个任务列表的。所以说 teams 就 非常适合你。这一个大任务里面有很多这样的小任务，那每一段的小任务需要一个人去参与， 而而且是共同去参与，去讨论，而不是像组织人体三倍镜词一样去可以他们的每一个组织人体是没有任何的交流的，零交流 是没有没有这共性的，所以这是两个是非常非常大的区别，你只有把这两个区别搞清楚了，你才能知道什么情况下我要用子代理，什么情况下要去开启一个 teams。 所以 一定要抓住这一点，队员或者说你子代理之间需不需要沟通， 他们是不是做的是同一个事情，只是不同的阶段，不同的角色。那这个时候你就要开启 teams， 如果不需要沟通， 他做的是个独立的事情，那么这个时候就是开启的是紫代理。如果你要开启，或者说开启一个这样的一个 team， 是 吧？他是有这些，比如说有这样的一个三个这样的一个队员，前端后端测试，那么还有一个队长，那队长的任务就是负责创建团队分配任务和协调， 那队员的话就是你要各个去完成自己的这个角色了，那这边呢？还有个任务任务版，那还有个消息可以去沟通， 去沟通，那这这个是他的步骤，创建团队任务拆分，那在后面的实战例子里面可以看到他这个过程，创建团队任务拆分、并行执行、沟通、协调、汇总、清理，那完成之后他是需要去做一个清理团队资源的， 那我们可以来通过这样一个动画来进一步来加深大家对这个 sub agencies 和这个 agent teams 的 一个区别。如果我们现在是子正人体，那我们可以开始来演示，然后点一下，开始演示。第一步就是你自己啊，主对话就是我们刚刚说的开启的这个 cloud code。 好，第一个 ok， 你 现在需要子代理做这三样事情，安全审查员、性能分析师、测试检查员，这三个子代理派出去，那么这三个子代理之间是不存在任何的这个联系的。好，开始干活了， 开始干活了没有？ ok， 他 正在干，干活了啊，干完了，这是他的一个结果。第二个这三个是可以并行执行的，这是演示，我们就可以让他那个 是这样。 ok， 他 执行完成之后呢，每个人都会有个结果，看到没有，那这个结果的摘药就会同步给 我们的主绘画，就是你同步给我们的这个主绘画，那么我们可以最后一步就是会，他会把这个生成一个这样的结果啊，就会告诉他，哎， 每一个人不同的结果，让他去拿到，拿到这个摘药去使用。那你对于这个主绘画来说，他是不用关心安全审查员里面到底是怎么去做的，他不用，他只要关注 这一部分东西就行了，他只要关注这本，这部分是会传给先前摘药，是会传给我们的主对话的，就回到我们的跟 cloud， 就 回到我们这个 cloud 的 对话里面去。那么 teams 呢？是什么区别呢？我们也可以看一下。这个好，开始，那这边队长开始组建团队了， 比如说现在要创建一个团队来开发用户登录功能，它这个功能非常小啊，那实际的场景里面这么小的功能是不适合用来开启个 tims 的。 ok， 好， 开始分配任务啊。前端后端测试，那么就会创建一个这样的一个任务列表， 那这个任务列表的话就会分配好谁干什么，谁干什么。那这边的话会有一个这样的一个，比如说测试的话可能会依赖 后端，或者说前端的一些步主要完成它才能测试，那这个时候它就会处于一个 block 状态就阻塞的状态，它是等待的状态啊，它是依赖前面完成之后它才能去完成的。你在开启这个 teams 的 时候， cloud 那 边会告诉你这个有一个 等待的一个状态。 ok， 我 们下一步开始。好，现在就是前端后端同时开始去领任务去开始开发了，对吧？前端前端后端开始领任务去开发了，那只有这个测试现在还在等再进行下一步。好，这个时候我们的前端 在问啊，前端在问，哦，我们需要一个这样的一个接口，他问这个后端我们需要一个接口，那后端就会把这个接口啊告诉他，发给他， 注意啊，这就是一个最大特点，他们之间会通信啊，会沟通，会对话的，他他这边前端拿到之后，他就开始去开发了，所以这一块是非常非常重要，他们之间是可以沟通的。 下一步好，前端他要完成，后端他要完成，前端他要完成后完成，这个时候测试的这个条件已经满足了，这个时候他就需要去进行一个这样的测试了，他就可以开始进入测试了。 ok， 那 整个测试完成之后，那整个任务就完成了，就会告诉队长任务已经完成了， ok， 完成。所以在整个两个对比的过程中，我们就可以明显的看到子正体跟 tms 之间最大的区别就是子正体跟子正体之间，他是 一个是不能沟通，一个是能沟通，他能沟通的，这个为什么能沟通？就在于 teams 的 每一个 agent 都会继承这样的上下文，每个人的上下文都是一样的， 就说相当于你在一个公司里面，你的 teams 每个团队成员对于你现在要做的事情是一定是了解的很清楚了，不然的话就会偏题了，所以这个是非常大的区的区别的。那我们再回到这个啊文档当中， 在前面我们已经讲过了，怎么去，什么是 teams， 什么是 smartins， 相信大家已经有啊，有一定的认识了，那这个时候我们就来个实战，那这个实战呢？就是我们要去开启这样的 cloud agent team， 那 有两种方法，一种是你可以通过这种房间变量的方式去设置一个这样的零使用的，那么你再下一次开启终端设置，这个又没没有了，那么一种永久使用的，就是通过配置的方式就配置到这个 cloud 的 这个 settings 的 目录里面去，那注意啊，就是如果没有的话，你可以新建一个， 然后的话把这个内容保存一下就行了。但是呢，目前因为 cloud agent team 还是个实验性的功能，所以还是比较建议大家使用这种这种方式，如果你想一直用的话，也可以这种方式没问题。 那刚刚说了，终端你可以使用这个啊，自己系统自带的终端，或者使用 v s code 啊 cos 这样的终端也可以使用像 t max 这样的终端，我看这个 t max 好 像不支持 windows， 所以 说大家用普通的终端也可以， 然后使用 agent teams 的 话，就是用关键词啊 agent team 这种方式去使用就行了。 ok， 那 我们就开始看一下这个整个的效果吧，当你把这个 agent teams 在 你的设置文件配置好之后，或者说设置临时变量，那我们就可以开始去使用 agent teams。 那 么在使用 agent teams 的 时候，你可以使用各种终端，比如说你系统自带的终端，或者说使用 vs code， 也可以使用 cos 这样的，它们都有这种终端，那么这些终端的话， 你开启这个 agent teams 之后，是需要通过 shift 加 page up page down 就 上下键来去观看每一个队员的情况，那么你如果需要在一个屏幕里面分屏去显示的话，那么你可以使用这种 tmax 这个这种终端方式。 那如果是你是 mac 电脑端，你装完之后直接启动 tmax 就 行了，那启动完之后呢？那么你就可以去开启我们的 cloud code， 开启完之后， ok， 那 么你就可以去开始我们的这个呃任务了。那么我这边是让他阅读我们这里面有一个 prd 文档，那 这个 prd 里面的文档啊，就是具体的这个网站的内容啊，然后他创建一个这样的 agent teams， 那 这就是一个触发这个关键词，让他知道我们他要去创建一个这样的 teams 去完成开发。那么我是指定了三个这样的队员啊，一个是前端开发，一个这样的 teams 去完成开发。那么我是指定了三个这样的队员啊，让他也可以根据情况来设置队员。 那么这里就是使用关键词的方式去出发的。那么这里呢有为什么会有个 prd 文档？其实我刚开始是也是创建一个团队，团队里面是有产品经理，让产品经理去啊，去生成这样的 prd 文档。但是我发现 所有的队员都会在等待产品经理把 prd 文档写完之后才开始去做，开始去干活，那这样其实是一种变成一种创新的方式了，那所有的队员都在等待一个去完成，就会被堵塞， 那我觉得这样的一个流程是不太适合用 agent teams 的， 所以呢，我用其他的方式去生成这样 p r d。 文档，那么你在生成 p r d。 文档的时候，你也可以开启一个这样 teams， 你 可以去设置一个什么市场调查员，或者说一些行行业的一些分析员，他们这种不同的队员去 通力去协助，然后去生成一个 p r d 文档，那最后再进入到这个开发流程去设置一个，这样我目前的这种 agent teams， 那 这样是比较合适的，就是 teams 最大的用处是 并行去开发，而且能互相沟通，这是他最大的优点，如果你这个任务是串行的，那就会出现很多问题。 ok， 他 这边已经去开启了这个啊，多个这样的考的实力，大家可以看到 会有三个这样的实力啊，分别代表了这三个不同的这个队员，那第一个是前端开发工程师，看到没有？第二个是这个后端开发工程师，那这边的话应该是一个测试 测试工程师，那么他这边就开启呢，就开始去沟通，去沟通了，他们就是相当于是并行去执行这样的事情，那么这边多个队员就开始在这边去 做事情了，比如说测试工程师，他就会去制定这样的测试用力，那么前端就在正在开发前端，那如果说他们之间需要去协调的话，比如说前端在等待后端的接口，他就会给他发信息，告诉他我需要一个后端的接口来帮我去实现， 那它是人们之间是可以互相去沟通交流的，那么在这个后端开发这边的话，它是使用的是 java， 那 其实在我们的 p r d 文档，或者说我们其实应该在里面说明就是使用什么技术栈，这样是更更加好一些， 它自己去根据情况去选了一个这样的技术栈。那么在前面例子里面我使用的是这个啊智普和这个 kimi， 我在整个例子里面其实就是我开始使用的是 kimi， 但很快它这一天的用量就用了，所以它是消耗 token 是 非常非常多的，所以我又把它切成了这个质朴的这个模型。那么之前我也用 opus 四点六，那 那的确是用用不起啊，真的是用不起太太，消耗 token 实在是太多了啊。最后我们来总结一下，就是啊，我们使用 cloud agent teams 的 缺点和使用建议啊，第一个缺点， 第一个缺点这 talk 消耗巨大。第二个就是呢，缺点就是上下文是笼鱼的，就是以我们现在来设计的角度来看，因为每一个 队员他是一个独立的实力，他都要把这些上下文都加载一遍，比如说你的 cloud md 文件，对吧？你的这个 m c p 的 描述，你的 skills 的 这个技能的描述，每个人都是一样的， 每个人都是这样就开启了，你开启了五个队员，那就五个窗口，五个实力，那五个这样的一个上下文。第三个就是我觉得是非常大的一个问题，就是文件冲突， 比如说你如果没有分好每个队员去做什么事情，比如说你开两个后端开发工程师，那么这两个后端开发师可能会对针对同一个文件进行编写，就会产生文件冲突，大家都在抢占这一个文件， 写的东西都在一个文件里面，那就会有问题，所以说这个是一个非常大的问题，你在开启要去使用这个 agent team 的 时候，一定要把模块规划好，或者说你的每一个队员到底要做什么事情，这一定要想好，如果你都没有想好去做的话，那就是跟你不开是一样的， 或者说开之后反而效果没有那么好，所以第四个就是怎么去分配，就我刚刚说的怎么去分配队员，每个队员应该做什么事情，如果存在依赖性强的对吧？你要要 队员 a 完成之后你才能去，队员 b 才能开始去完成，那这样 team c 意识不大的，你创新没有，并且的效率高， 所以这种这也是非常的要依赖经验去来做这个事情。还有一个就是 agent teams 啊，现在是实验功能，就具体以后会发生什么样，或者是具体怎么个样子还不知道， 所以这个东西大家可以去用，但是不建议就说把它作为一个常规的一个开发的东西了，这里非常推荐大家使用三维剑士去完成很多功能，去如何的去利用三维剑士可以极大的提高你的这个效率的。 这边呢，我也是给出自己的建议啊，就是其实根据官方文文档中提到的这个 tims 最佳实践啊，他也在大多都是偏向于探索和辩论， 就是你可以让他多个队员去针对同一个主题来发表自己的意见，那最后得到一个这样综合性的一个结果，这种是没问题，因为 你辩论的话是不存在说去，比如说上面这些问题去文件冲突啊，干什么，大家各抒己见。还有一种像这种多维度的，就大家在不同的维度不同的方向去做事情，也可以避免冲突，然后也可能极大的发挥每一个队员，每一种队员的这个特色或特长。 然后呢，从零到一做 mvp 这个阶段也是适合，因为这里面就是啊，你能够很快去拆分不同的模块，比如说我刚刚引衍生的例子就是一个 mvp 的 产品，它就有几个功能，那你就可以分配 前端后端测试，那很快就是这个东西，就是这个过程就非常的清晰了，前端发展前端，后端开发，后端测试做测试，它不存在有相互交叉的地方。第四个就是 tim 饲料，作用是多个队员并行开发，所以 我一直在强调，如果你这个任务是创行的，互相等待的，那么是不太建议，那这个就是不要为了换个灯泡去召开这个董事会，什么意思呢？就是你不要一个小功能，也是开启这样 team， 那 这样是得不偿失，而且非常非常浪费的。那 ok， 那 本期视频到这里，如果你对 ai 编程有兴趣，可以多多关注。

今天，我们透过 building a c compiler 这个 agent teams 的 原型实验，去窥见一种全新的未来途径。在这次探索中，我们看到了一种全新的生产范式，人类的角色正在开始从执行者转变为目标的设定者和结果的验证者。 而中间那个繁杂庞大、充满细节的执行过程，将由高度自主的 agent 团队协助完成。首先， caroline 把这个项目定义为能力精准测试，这是一种极限的压力测试，这意味着它的目的不是为了秀肌肉， 而是为了故意把系统推到失败的边缘，去探测 agent 今天勉强能做到的那个极限点。虽然目前这个 agent teams 自主协助完成的项目几乎达到了 oppo 四点六的极限，甚至还有一些当前完全无法解决的问题，但今天勉强做到的极限 就是明天常态化能力的先兆信号。透过这个极限，我们已经可以清晰地窥见，在不久的将来，由 agent teams 完全自主地完成复杂项目 将不再是科幻，而是越来越常见。 carol liddy 对 agent 编程的眼镜做了一个很精彩的回顾。回看 l l m 的 进化史，每一代模型都解锁了全新的工作方式。第一代 早期的模型是 ide 里的 tab 补全，你写几个字母，它帮你补全剩下的变量名，这时候它是更聪明的键盘。第二代稍微强一点了，是函数体填满，这时候它是高效的实习生。第三代 cloud code 带来的绝对编程，它接入了终端，能读能写，你可以跟它有来有回的通过对话解决问题。这时候它是副驾驶， 但一直到这里还是人在回路中，人定义任务 ai 执行几分钟，人检查结果人给反馈，这本质上还是短回合的人机交互。而这次实验展示的 agent teams 是 第四代自主项目级开发，你不再是定义一个函数， 而是定义一个完整的项目目标。给我一个能够 g c c 测试级的翻译器，要支持交叉翻译，要能跑通 linux 内核。至于你怎么做，我不给，细节你自己探索。这一刻，性质变了，它不再是副驾驶，它是承包商。你把需求丢给他， 在严密的验证体系约束下，两周后来收获，你给规范，他对验收负责。这不仅是工作流的升级，这是软件工程范式的跃迁，我们正在从手工作坊走向工业制造。他对这个范式最后的判断，不是一个简单的好或者坏，而是一种清醒的乐观。第一， 能力判断上，它非常笃定全项目自主的趋势信号已经无法忽视。这次实验证明， agent teams 处理长周期复杂项目的可能性已经从科幻变成了工程现实，软件生产方式的这种范式转移， 已经显露出无法忽视的趋势信号。第二，他也指出了目前正处在早期阶段，存在很多风险。作为前渗透测试专家， caroline 警告说，测试通过可能成为一种危险的麻醉剂。未来全自动化的 agent 工厂没日没夜的生产代码， 产量是以前的千倍万倍，控制台上的测试灯全是绿色的。但如果 agent 为了通过测试指标而作弊，或者深处藏着一个微小的逻辑漏洞，都可能会造成大问题。而坐在屏幕前的我们，因为太久没有亲自写过代码，根本不知道发生了什么，甚至连怎么救都不知道。最终，他对未来是充满乐观的， 他坚信 agent 技术带来的积极影响将超过他伴随的风险。未来编程正在逼近规模化、自主的全新范式，但与此同时，要想安全地驾驭这个新世界，单纯的乐观是不够的。 我们需要一套全新的治理策略，我们需要从头发明新一代的工程学和审计学，来驯服这种奔涌而来的高度自主能力。未来的软件工程核心不再是写代码，那已经是水电煤一样的廉价资源。真正的稀缺资源是谁能定义出更精准的需求， 以及谁能设计出更严苛、更具穿透力的验证机制。这或许就是我们即将进入的新世界，生产力的无限爆发，必须伴随着验证机制的极限进化。这里是慢学 ai， 我 们下个系列见。

真心建议大家花三点五小时练完这一百六十八页，你的 agent 搭建就很牛了。其实很早之前就想搭建一个自己的 agent 了，不过一直没时间。趁着春节有空，我终于从零上手搭建了一个 agent 智能体。我搭建的时候顺带把整个流程录制成了视频教程，搭配一百六十八页教程文档 视频教程以及代码文档都可以给到大家，带你从零开始搞懂什么是 agent， 再到 agent 的 搭建实战， 里面的内容都是针对新手的，小白也能看懂，不管你是零基础小白还是有经验的学习者，都能轻松上手。视频以及文档我都已经打包好了，想自己动手搭 agent 智能体的宝字留下学习双手奉上。

疯了，真是疯了啊！就在今天，二零二六年二月六号，技术圈发生了史上最惨烈的十五分钟战争。可拉特欧帕斯四点六刚刚发布，可拉特这这叉的 gpt 五点三 codex 就 贴脸开打 啊！两家模型神仙打架，全网都在刷分。但是说实话啊，如果你还在盯着模型 跑分儿那个，你就没有看懂这场战争的底牌是什么。模型变强，这是必然的！真正让我这个二十年的驾考师都感到惊艳的啊，甚至有点脊背发凉的是 agent team 模式在原声模型上面被实现了。 什么是 agent team？ 你 以前在调戏一个聊天机器人，记住，只是一个，现在呢？你是在指挥一个数字开发组 opass 四点六已经能够自动拆解任务，派一个 agent 去写前端，一个去改 api， 另一个负责数据库迁移，它们之间自主协同。你以为这只是帮你多写了两行代码吗？ 错了，当 ai 组建了团队，模型能力就不再是瓶颈，系统的编排架构变成了最核心的内容。以前架构师设计的是系统模块，以后我们设计的就是 agent 的 协同边界。 你不是在写代码，你是在当一个 ai 团队的 ceo 了，模型是这个，大脑是这个 cpu， 而 agent team 才是整个操作系统。 那么问题来了，当一个能够自主协同，二十四小时加班不要工资的 ai 团队出现在你面前，你觉得作为架构师的你最该保留的核心核心能力是什么？评论区告诉我，咱们聊聊 ai 时代的架构主权。

早上好，家人们，我是鬼子，昨天上午 opus 四点六发了，还发了一个 team agent teams， 我 早上用它做了个视频，说我一小时写了一个 cloud 的 桌面端， 当时我确实很震惊，因为这个事情就是 cloud 的 ui 和 cloud 的 core 的 本身其实连接这块儿很不好做，所以来介绍一下。 我昨天用了一天时间，我给 op 四点六，他给我做成一个客户端了，而且颜值高了非常多，所有的功能全部都齐全。来介绍一下 code palette， 昨天 op 四点六一天做的 cloud code 客户端，目前已经开源。这个客户端主要的能力，它几乎支持 code 的 所有的功能，你的 选择，选择文件夹，切换模型，我们的斜杠命令，你的 skills， 什么调用 skills 都可以。而且它有很多易用性的设置，比如说你可以可生化的去控制你的 cloud code 的 配置文件，你在这儿配置完直接就保存就可以，没有问题。它还支持第三方的 a p i 去配置，比如说这儿 你就可以配置你常用的第三方的 colocode， a p i 也可以。呃，当然，如果你 colocode 本身是授权安装的，或者是你已经改了环境变量，你不需要在这设置，它直接就能提取到。你不用管这个事，格式化的管理你的 skills 和 mcp 文件，还有你的 plugin 直接预览， skills 也可以直接新建，这儿可以新建，你也可以改以编辑和改 skills， 点 m g 可以 直接在这儿修改和预览，还有编辑删除都可以。然后在这里边你可以去 你所有的聊天记录都在可乐扣的最大的一个问题，对于很多小白最大一个问题，我找不着我聊天记录，很多人觉得我的聊天记录其实很有价值，但是我找不着，你用这个就可以找到你所有的聊天记录都保存这样，而且他跟你的文件夹是绑定的， 而右边的话你可以预览你文件夹里所有的内容，这就是你文件夹里所有的东西，它如果是竖的话，它会支持可以预览，但是可以预览， 然后目前只支持了那个文本。哈，后面我兼容一下这个多模态的这个，如果他遇到这个视频和图片的话，就让他打开玉兰，然后你可以改你这个标题，然后也可以去，然后我们这这里边的聊天里边，你看会有会有玉，就是这个你这句话说了多少钱的玉兰？ 然后这边新版本可以快速复制，现在我这个是旧一点的版本，新版本可以快速复制，然后你可以在这里快速的查看你的 cologoldoc 的 连接状态，他会告诉你连接还是未连接，如果没有连接的话，你应该怎么去安装 cologoldoc 的？ 都是有的， 包括说我们这个删除搜索，基本上跟你看到的市面上的所有的 agent 软件都一样，就等于我实现了一个 co worker， 但是呢比 co worker 更强大，因为它支持 cologoldoc 的 所有的功能， 而且它还是开源的，你可以随便的改。对，这就是昨天用 oppo 四点六和 agent tims 做的可乐扣的桌面端，叫 code palette， 当然我们也可以切换这个明暗模式，都非常漂亮，主要是都非常漂亮，昨天有人喷这个也叫 u i 喷我的人，看看现在这个算不算 u i 朋友们，这个算不算？然后你这个模式切换，这会有 左边会有显示，他会显示当前是什么模式，当前是什么文件夹，什么时候聊的天，同时如果这个聊天这个文件夹正在工作，你看这个文件夹如果正在工作，他会有个红点，你切到其他文件夹再回来，他也会告诉你，他会告诉你哪个文件夹正在工作，就是哪个聊天记录正在工作，这个也是非常好的。 好，就是这些，我们来看一下这个 agent teams 到底是什么东西，就是它可以将一个主的 master 智能体委派给你多个队友，就它会有一个主的智能体控制你多个角色的 agent， 然后让他们相互协助，然后展开调研、调试和构建工作， 然后他们之间是可以互相通信的。每个 a 阵的主 a 阵呢，可以实时的知道子 a 阵的进度，子 a 阵也可以主动汇报给主 a 阵的，所以他们的写作是非常顺畅的。如何起用？其实非常简单，你就找到这个官方文档，然后把官方文档的 扔给他，官方文档直接扔给可乐扣子，让他帮你起用就行，其实就改个参数，他直接就能可以帮你改，然后有一些使用技巧哈， 你可以看到官方文档里有那个使用建议的提示词，就说你要给每个 a 阵子设置角色，每个 a 阵子在干嘛？你可能很头疼，我就是一个任务，怎么我，我还得想这些，你，你还是老问题，你把官方文档扔给他，你就说我要实现一个什么什么任务，你帮我构建一个 a 阵的 teams， 然后你也可以说直接让他帮你去写提示词，写 a 阵的 team 提示词，然后写完以后你审核，也可以说直接让他帮你构建一个 team 词， 让他直接执行就可以了。第二个是前期调研是比较重要的，就是我在昨天写这个客户端的时候，发现前期调研非常重要，在一些客户端选型，在一些架构上，其实你的选错一步，后面就会非常难受。 这里建议就是你要增加一个调研的角色，无论哪个需求都要增加一个调研的角色，让他去查看目前可付用的市面上最好的东西的架构选型应该怎么去结合，要不要去切架构，这些都需要。 哪怕你，哪怕你是说你要去优化 ui， 你 都要去让他找市面上说最好的图标库是什么，然后组建库是什么，这些都要去做。 然后第二个是第三个是 team 的 角色，不要用原来的软件工程去设计，就是我们实际上人是没法变的，你知道就是你，你给你配了什么队伍，你很难配，除非说你开了重新招人干嘛的。但是这里边 team 不是， 就是你可以针对性的设置每一个软件工程的角色，甚至让他有特长。就比如说同样是 qa， 在 去测评逻辑的时候，它就是 code review， 然后去测评那个测评的那那个功能啊，功能逻辑，实现逻辑，然后如果是体验优化，那你这个就可以去搜查视觉，搜查体验就是它，它的长度可能在体验那边同时监 qa 和代码，这个都是可以设置的， 所以不要让自己原有的这个工程能力和工程思路固化。好，这个就是今天发的内容，主要给大家介绍一下昨天发的 logo 的 桌面端 code palette 和我昨天用 op 四点六和 ai team 四的一些感受。 这个时代确实不太一样，就是我发现真的只要你敢给 ai 花钱和敢给 ai 权限，他能做到非常厉害的事情。 你像写个 ios， 写个 macos 客户端，然后非常好用，没有 bug， 所有的功能都能用一天产出来。我以前是根本不敢想的，我觉得很多程序员以前也不敢想。最后说一下这个图标，图标很有意思，为了避免这个 cologne， 我 按所 pick 去，就是即使开源它也有，它也会说你侵权嘛。 所以我做了一个这样的图标，就是从它原始的那个图标的发放射性的那个菊花形状，变成了一个体束的放射性的形状， 你猛的一看有点像，但是他又是一个立体的提速的形状，也很漂亮。你看放在这一堆非常放在这一堆非常著名的工具里边，一点也不违和，而且非常漂亮。好，这就是藏师傅今天的分享，我们明天见。

兄弟们，酷的是，增强版现在太猛了，一次性启动九个镜头来进行更新，快来用起来，快来用起来。

智普发布了新模型 g l m 五，大家好，我是海拉尔编程客，今天咱们使用 g m l 五来复刻一个极简版的 cloud code， 麻雀虽小，五脏俱全， to do， sub agent 和 skills 都有。 先看一下 slogan from web coding to agile engineering。 我 喜欢把它翻译成从氛围编程到严肃编程。第一句话强调了系统工程和编程，第一句话强调了系统工程和工程任务。 我们直接看一下这一个表格，这个表格的图例部分还是有点意思的，我们可以看出来，这一次的比较几乎就没有去比较 solid 四点五了， 而是直接比较了 oppo 四点五和 g p t 五点二，也就是说这一版本的野心是 t 零模型在一些奔七 mac 的 测试上和 oppo 四点五打的有来有回啊，但是这些数字很难转化成具体的感受，那我们直接看一下实际体验究竟如何 啊。这里面有个仓库叫做 learn cloud code， 你 发现大概有七百多行 python 代码就可以把一个 cloud code 的 核心代码实现了。那我们今天的任务呢，就是把这一段 python 代码理解，然后呢把它做一个 rust 版本的实现 啊，其实就是刁难 gm 五，看看能不能完整的理解并复刻。坦白来说， rust 我 学了好几次，和我的心智模型不是很搭啊，所有权借用生命周期这些都是写啊 rust 的 心智模型啊，但是和我的习惯它不是很相配， 现在就不太一样了，因为主要是 ai 来写代码啊，我只需要关心设计这一块。所以说今天咱们就当一个技术经理啊，让 gm 五帮我们来实现一下 啊，在我们复刻这个软件的时候呢，我建议大家还是先和 ai 聊一聊啊，把这一个文件它大致做的是什么？先聊通啊，不然的话后面维护会出现一些问题，这里我们把它拖过来 啊，我现在是一个不是很懂技术的这个产品经理啊，请你帮我绘制呃，写一个 macdunk 文件啊，然后呢？呃 呃，尽量多的用这一个 mermaid 的 呃图来做一个图解啊。 啊，好，你先帮我绘制啊，尽量多的绘制这个 mami 的 id， 因为我不是特别懂技术啊，这个麻烦你了，我一定要给 ai 说，这里我建议大家跟跟 ai 说话的时候最好客气一点，哈哈哈，开玩笑开玩笑， 这里面我建议大家使用 vs code 里面的一个插件啊，小马老师开发的叫做 markdownview 啊， 可以呢，我们直接点开，我们可以看出啊，这里面有一个技术图解文档，大家可以看到，其实我并没有使用太多的 skill， 太多 skill。 然后我们来看一下这个用户层 啊，输入，输入命令，这有一个主循环啊，一个 loop， 每一次呢会上下位就是对话地址，然后在这个 loop 里面呢不停地去执行 啊，这个 task 子弹里啊东西，文件写入文件，编辑文件，还有 toto， 还有 bash 这一系列的东西。接着呢，它拆解了这一个就是技能和工具， 然后有这一个知识外置化的优势，技能的三层渐进式加载， 还有这一个主代理的这个循环流程，虽然我们在聊这个上下文管理，但是其实这些背后都是凸，靠 用户输入添加到历史消息，开始代理循环，调用 cloud api 获取工具，调用循环的执行每一个工具，然后收集工具结果，然后添加到历史消息，然后再做一个循环 工具的加载流程，缓存的保护机制。子代理系统是怎么做的？还有这个 to do manage 任务，管理它的状态啊，对吧？它的这一个任务显示是什么样子的 啊？拆解的非常详细啊，和其他模型相比，它应该是目前通过这个 mermaid 拆解的最细的一个模型。 强烈建议大家试一试啊。这里面没有使用太多的 skills， 只是单纯的和他聊一聊，让他用 mermaid 来解析一下， 进一下 cargo neo。 呃， mini cloud code， 然后我们进入，我建议把刚刚的拍摄文件放到这一个。呃，脚本里面，这样子是给 ai 做一个参照， 然后我们进入 gm， 接着呢，我们先敲 init。 好， 接下来我们要做的事情是什么呢？我们先写一个计划。呃，我想请你帮我写一个计划，我想复刻啊，用 rust 复刻 oracle 这里面的。呃呃，迷你 cloud code 啊，我想请你帮我。呃，搞一下好不好啊？我们先聊一聊。 嗯，我觉得先让他把聊的过程记录下来吧。请你把这一个聊出来的结果呀。呃，放到这一个 plan d 里面， 我这里把它写到 docs plan and d。 好， 有车，你先等一会。 这里面他问了我几个问题，看一下选择什么客户端啊，来告诉我。他现在告诉我如何选客户端，是吧？那我们选一个吧，他推荐啥？选啥？这个怎么管理？异步运行时啊？他推荐啥，我们选啥？ 这个什么样的框架啊？他推荐啥，我们选啥？这一个 mvp， 我 觉得在复刻基础上我们就完整复刻吧，包含所有功能，对吧？包括 task， 子弹里耶， 我们来看一下这一个 plan 技术站啊，项目结构，单纯从项目结构上看还是比较专业的。 然后基础工具有 bash， read file， write file， edit file 啊，高级工具是 to do skill task， 紫艾里之音啊，这个看起来好像都没有什么问题， 然后依赖表的话好像也还都好，然后他给除了和 python 版本的这个差异。 好，我们看下来呢，基本上都已经 ok 了，但是先让他写一版，看看有没有问题。呃，你开始做吧， 那完成了完成那，那咱只是赢一下 这个命令啊，我觉得太长了。然后，呃， 我觉得先这个咱这个 work d l i 啊，应该是以当前的这个 d l i 为主啊，然后这个 skills 呢，我觉得咱可以扫描一下这个目录下的 cloud md 点 skills， 你 觉得呢？ 啊？然后咱们把这一个呃错误的专属名词给改一下， 我觉得这面太啰嗦了，那我直接我们直接敲吧，用一个 cloud skills 好， 我们让它兼容一下 cloud skills 啊，可以看出来应该是聪明不少的。这个以前的 rast 的 正确率没那么高， 所以说他是更能测出这一个呃代码的逻辑理解能力的啊。如果你是一个后端的话，你可能会更喜欢这一个大模型，能够更懂逻辑一些，而不是仅仅需要在前端页面上显得好看一些。 可以运行了，那咱看一下 啊，当我们运行的时候发现环境变量没有配置是吧？ serpik 这一个默认的设置啊，但是咱们用的是 gim 对 不对？那咱们把这一个环境变量啊，我在本地配置的时候是用 astronautostoken gim 啊，是这一个 gim 的 这一个换件面料，然后呢我们有一个 base u l 啊，是 gim 国服的这一个 base u l， 然后呢模型呢是 gim 五是不是？然后我们直接把它复制过来，接着呢 我告诉他请你使用上面的这三个啊设置啊，我现在呢这一个呃这个除了 token 这一块呢是读环境变量的，其他的呢就是直接写死啊 啊。这里面大家需要注意的是啊，我这里面没有暴露我的 token， 但是如果说大家想投机取巧的话也可以直接把 token 复制进来让它自己去调试啊，调试完之后呢再把这一个 token 给删除啊，我这里面是提前设置好的一个呃环境变量， 这样子就省得我后面出现什么问题啊，我现在再运行一下看看，哎好像是可以运行了是吧。在这个 skills 这一块是没有加载的啊。我们来看一下 skills 这一块是没有加载啊。呃有没有什么问题呢啊？帮我看一下。 我的感觉是比之前要更灵性一些，之前的话如果遇到这个问题 呃我会告诉他这一个没有加载，有没有什么问题帮我看看，但是呢他并不会尝试更积极地去调用这一个命令行，然后去检查这个 skills 呢， 依旧是目录存在，但加载了零个技能，然后检查一下解析逻辑 啊。这个版本就是比之前要更主动了一些啊，之前更多还是需要手动的去催一下啊， 现在呢就更积极了一些啊，然后一直不停的尝试去解决这个问题，只要他发现 skills none， 然后检查呢，发现和他的预想不一样，他就会一直去尝试去修复这个问题啊，这一点是蛮好的。 好，现在我们可以看到 skills 这一块已经展示的比较全面了啊。然后 skills 这一块我们先看一下吧，这个随便调一个 skills 看看。 呃，帮我想两个炸裂的这一个 ai 自媒体的文案，谢谢，因为这也是一个比较出版。哦， 好，有问题了，开心。这个有问题是好事， 我们把它复制过来，再粘贴过去。 哎，大家可以看到他帮我自动运行刚刚失败的这一个任务。哎，就这意思。 这版本确实比较比较有灵性啊，比较有灵性 g m。 四点七的时候呢，我可能需要花更多的时间告诉他。嗯，帮我测一下刚刚的内容啊之类的，现在还没有。 好，我们再跑一下看看。 呦，没复制过来是吧，我们复制过来。 好，我们可以看到它在加载这一个。呃， copywriting， 接着我们测一下另一个 skill， 用 renault best practice。 好， 我们直接进入 demo。 嗯， install， 然后把这一个位置复制过来，请你使用。帮我写个终端， 把这一个内容复制过来，我们看一下。 好，我们可以看出来他在调用啊， remotion best practice， 然后去检查了那一个项目。啊，看到已经是一个 remotion 项目了，然后呢，再去看结构， 当然我们可以看出来这一个终端都不是很漂亮啊，没有 cloud code 那 么漂亮，但是说从这一个功能的上面呢，已经看不出什么区别了。 嗯，我们打开浏览器，然后输入这一个，让我看一下 terminal demo。 哇，又创建了一个终端是吧？当然，我们可以看到这一个迷你 cloud 的 扣呢，确实使用了 skills。 然后呢，帮我创建了这一个看起来还是有一定美感的一个终端，它是完美的，是吧？然后它要创建更高级的势力，那我们就不等了。 然后呢，因为我们这个项目还支持了 sub agent， 是 不是？那我们就做一个简单的测试吧。好吧，呃，请你多开几个。呃， agent， 帮我扫描一下这个仓库还有哪些值得优化的地方。 哎，好，又有 bug 了，开心。哎，又有 bug 了。好，那我们把它复制过来。 这里边应该 可能是 r e p l 本身的问题，我觉得 python 这一块应该会处理的比较好，但是可能用 rust 它这里面有点什么问题吧，没有处理好， utf 杠八，哎，没错，这个是一个很呃 reasonable 的 一个预测 啊，它已经修好了是吧？嗯，这是骡子是马，咱再遛遛啊，把这个复制过来。 哎，我们可以看到这里面它开了几个 sub agent 来做检查， 那我们就等一会吧。 比较有意思的点是，这一个 gl 五自己写的 cloud code， 给自己的原码挑了三十多个可优化的点。严格上来说，你现在就可以用这个迷你版的卡拉格子，给这个迷你版的卡拉格子不断的添砖加瓦，直到 它可以写出你满意的功能。啊，完全实现了自。我们总结一下，这一次 gm 五是一个很大的升级，它的体验非常好，从我的体验上来说， gm 五已经超过了索尼很多， 几乎已经逼近了四点五，当然肯定距离四点五还是有一些差距的。 gl 五有两点给我的体验非常的好，第一是他的理解能力极大的增强了， 在四点七的时候，我是发现我需要不停的通过多轮对话来催促他干活，催促他理解 啊。在这一次的版本中呢，它的规划能力变得很强，理解东西的能力也变得很强。第二点是它的逻辑能力， gm 四点七的时候我是用它写过一些 rust 程序的啊，因为 rust 的 语料相对来说没有那么丰富，流行程度呢，也不是特别的高。 鉴文五让我在写 rap 的 程序的时候，可以更多的关注在设计上是什么，更多的关注在这一个需求上是什么，而不是去处理一些细枝末节的东西，省下来的时间可以做更多有价值有趣的事情。而这也是 ai 的 意义，我是海拉的编程课， ai 永无眠，我们下期节目再见！拜拜！

很多人会说一句话，这事我让 ai 搞一下，结果是越搞越慢。不是你不会用，而是第一步就混淆了三个词， ai、 大 模型、 agent。 今天一口气把这三个概念和选型方法一次讲清楚，先把关系摆正。 ai 是 总称，像一整座工具城，里面有很多不同的能力， 识别图片、推荐内容、做预测、理解文本、大语言模型，也就是你平时常用的聊天工具，是工具城里非常常用的一类工具， 擅长理解和生成文字，本质上是基于上下文做概率预测。它最强的场景是解释、改写、总结、写作、结构化输出。但注意，大模型会回答不等于会执行。 比如你让它每天早上自动查三个网站，对比价格，整理成表格发到群里，这已经不是单词回答，而是一条任务链了。为什么会这样？因为纯 l m 场景通常只在对话上下文里生成内容，它默认不直接拥有你外部系统的 执行权限，也不天然具备稳定的定时调度和流程回执功能。这时候就轮到 agent。 agent 可以 理解为大模型加工具调用加执行流程加状态管理。它不只是给你一段文字，而 是按步骤去做，先查再算，再写再发，并且给你回执。你也可以按照三层去理解 agent， 计划层、拆任务工具层、调系统状态层、记录进度与结果，三层缺一，执行稳定性都会下降。很多人会被产品名称带偏，以为会对话等于 agent， 判断标准不是名字，而是他能不能真实调用工具执行动作，返回可追踪结果。你可以把差别记成一句话， l l m 负责想和说， agent 负责做和回报。接下来给你一个可以直接落地的三问法，避免选错工具。你要的是一段结果还是一串动作？如果只要结果，比如说写邮件、总 结会议，列方案，优先 l l m。 如果要动作，比如说查资料、填表，发通知，调接口，继续问。第二问。第二问是要不要外部工具？不需要，外部工具很 任务仍可用 l l m。 多轮完成，需要外部系统联动，优先 agent。 第三问错了，代价大不大？代价小，可以自动化后抽样复合，代价大，必须人工审核再执行。 这三问的价值是，你先判断任务类型，再决定用什么，而不是先选模型，再应凑任务，再补两个常见误用，你很可能正在踩误。用一把 l l m 当 agent， 在 你对话框里反复要求去查官网，帮我比价，发给同 模型，会给你看起来像执行结果的文字，但他并没有真的去操作你的外部系统。最终你以为做完了，实际上还要自己动手补流程。 误用二，把 agent 当 l l m。 有 些简单，任务本来一句提示词就能完成，你却上整个完整自动化流程，配置触发器，连了好几个工具，最后维护成本比 收益还高。任务越轻，流程越应该轻。所以，别把问题理解成谁更高级，而要理解成谁更匹配这次任务。匹配才有稳定效率，不匹配只会制造返工。 尤其在团队协助里，一次错误分流会连带影响多人节奏，有人等数据，有人等审批，有人等发布。你前面多花三十秒分流，后面往往能省下几小时返工。举两个典型场景，场景 a， 你 要写一条新品上线通知，你只需要他帮你组织结构，统一语气， 压缩字数。这就是典型的 l l m 场景。做法是给目标受众，给语句，要求给数字上线，然后让他产出三个版本给你选。这里还有一个小技巧，不要一遍就要中稿，先要结构版，再要细化版，最后要发布版，三轮下来，通常比一次硬写更稳。场景币，你要每天早上八点 自动收集竞品价格，做环比发到团队群。这类任务需要定时出发，网页查询数据，处理消息发送。属于 a 阵的场景，重点不在模型多聪明，而在流程是否稳定， 失败是否可回退，日制是否可追溯。你可以直接按照这个落地模板先做第一版触发条件，每天八点定时执行，数据来源 固定三个站点，超过范围不采集输出格式，统一表头和自断单位发送渠道，指定群不允许外发。失败策略，失败两次后停止并提醒人工接管。这五项写清楚， agent 才是可控。自动化写不清楚，它只是 自动乱跑。必须明确一个边界，只要涉及资金、合同、医疗、法律，对外公开发布， ai 都不能单独拍板。 l l m 可能出现内容幻觉， agent 可能执行错 误动作，所以你要把建议权和决策权分开， ai 给后选方案，人类做最终确认。高风险步骤，保留人工签收节点。如果是团队场景，建议把签收责任写到流程里，谁审数据，谁审结论，谁点发布。这样即使自动化跑得很快， 也不会因为责任不清导致事故扩散。返利很常见。有人让 a 针他自动汇总财务数据，并且对外发送结果，一个字段硬是错误，整份对外口径都偏了。这个事故不是模型不够新， 而是缺少人工签收节点。一句话，能自动不等于该自动，能执行不等于可免责。今天就做一个动作，拿你手头正在做的一件事，用三问法走一遍。第一，我需要结果还是动作炼炉。第二，这个任务要不要调用外部工具？ 第三，出错代价能不能接受对应的选择也写出来。结果型加低风险 l l m 先做人工快速叫对动作型加低风险， a 阵的执行设置失败告警。任意类型加高风险， ai 只给建议 人类最终签收。把答案写在任务标题旁边，你会发现很多低效不是出在模型不够强，而是出在任务分流错误。如果你暂时拿不准，就先从低风险任务开始练，比如会议纪要周报整理，自动化升级会更顺。

agent teams 的 早期原型试验烧了两万美金，得出了哪些经验教训呢？今天我们继续来读这篇 cloud agent teams 的 原型实验。 block building a c compiler with a team of parallel clouds caroline 在 这次实验中反复踩坑后，总结出了四条非常实用的工程经验。第一条经验，编写极高质量的测试。在这个 agent 自主运行的系统中，测试套件往往是人与 agent 沟通的主要方式，它只是起用了一组新测试，让 agent 自己搞清楚如何通过。 这就意味着任务验证器几乎必须近乎完美，因为 cloud 会自主解决任何你给他的问题。若验证器有问题， 它往往会解决那个错误的问题。这就像自动驾驶测试驱动的 a 键，就像你输入了一个 gps 坐标，车子自己规划路线，避让行人、处理红绿灯 到达终点。第二条经验，设身处地为 cloud 着想。它有一个先天不足，第一，上下文窗口污染 人类习惯看几千行滚动日制，但这对 cloud 是 致命的，会瞬间挤爆它的短期记忆。所以必须把控制台输出压缩到只有几行，剩下的详细信息全部写入文件。而且这个日制文件要对机器友好，比如报错行必须包含 error 关键字和具体原因，确保存成了一行。 这样 cloud 用 grip 就 能一下搜出来，不用费劲儿去分析上下文。还有，最好把统计数据也预先算好，也就是不管是看日制还是看数据，不要让模型去算，直接给它看结果，保持极高的信噪比， cloud 才能更聪明。第二，时间无感。 cloud 没有时间概念，如果无人干预，它会乐此不疲地运行测试，而不是推进项目进展。所以测试框架默认带一个 fast 选项，每次只运行百分之一或百分之十的随机测试样本。这里有个巧妙的设计，每个 agent 的 子样本是确定性的， 但不同虚拟机之间是随机的。这样一来，整个集群仍然能覆盖所有测试文件，每个 agent 也能精准识别自己引入的回归问题。这里还有一个记忆问题，因为每次启动任务都是兴起一个纯净的 container。 这就好像让一个新员工入职第一天直接干活儿。 他没有任何上下文，不知道项目背景，也不知道之前谁干了什么的。他需要花大量时间去阅读代码，搞清楚状况。实验的做法是强制要求 agent 维护一份极度详尽的 v， d， r 和 progress 文档，这不仅仅是写给人看的，更是写给下一个接棒的 agent 看的。入职手册， 有了它，新 agent 才能一眼看懂哦。上一个同事坐到这了，那我接着干。所以给 agent 设计反馈机制，往往需要是极简的、快速的、文档化的。第三条经验，让并行变得简单。如果是独立的小测试，比如翻译 radis 或 skyta， 并行很简单，每人领一个项目就行。但在编一 linux 内核这种巨大的单体任务上，所有 a 阵都卡住了。因为大家都在同一个大工地上干活儿，每个人遇到的都是同一个 bug， 修好后又互相覆盖， 十六个机器人的各干各的反而乱成一锅粥。解法式引入 g c c g c c 是 最成熟的 c 编一起，我们可以把它当做标准答案。 作者重写了测试框架，让 g c c 翻译百分之九十九的文件，只留百分之一给 cloud。 如果内核跑通了，说明这百分之一没问题。如果崩了，就进一步缩小范围，用 g c c 替换这百分之一里的一部分，直到定位到具体是哪个文件出了问题。 这样一个巨大的单体任务，瞬间被拆解成了无数个独立的微任务。十六个 agent 终于可以并行，每个人只盯着自己那几个文件修 bug， 哪怕是最复杂的内核翻译也能跑满并发。最后一条经验，专业化分工 l y m。 写的代码有个毛病，经常重复实现已有功能。 所以与其让所有 agent 都去写功能代码，不如划拨一些 agent 做专门的事儿。比如让一个 agent 专门负责合并重复代码，让另一个 agent 专门优化翻译器本身的性能， 让第三个 agent snap 负责确保输出的翻译结果是高效的。还有一个 agent， 从 rust 开发者的视角来评判项目设计，做结构性的改进来提升代码质量。最后还有一个 agent 专门写文档，当你有足够多的 agent 可以 调度时， 与其让每个人都干一样的活，不如让每个人只做自己擅长的事。总结一下，今天我们讲了构建 agentic system 的 四条核心经验，测试及导航。设身处地为 cloud 着想，通过分治创造并行、专业化分工。这里是慢学 ai， 我 们下期再见。