目录
- 从终端工作流到 Firstmate [00:00:00 - 00:10:00]
- 让 Firstmate 成为唯一入口 [00:10:00 - 00:20:00]
- 用语音和可视化工具协作 [00:20:00 - 00:30:00]
- 把 Agent 系统做成可扩展的软件 [00:30:00 - 00:40:00]
- 独立开发与软件的重建 [00:40:00 - 00:50:00]
- 开源工具与社区 [00:50:00 - 00:50:52]
从终端工作流到 Firstmate
David Ondrej：欢迎收听跨国串门计划,这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的AI生文、克隆技术,我们不仅将内容翻译成中文,还完美保留了原主持人和嘉宾的独特声音,为您呈现全球顶尖的AI财经。健康与科技领域精品内容,我是主播一凯,一位热衷于AI领域的产品经理,很荣幸能为您搭建这座跨越语言障碍的桥梁。接下来让我为您简单介绍本期我们克隆的这档节目，本期我们克隆的是知名播客David Ondrej在2026年7月17日更新的一期节目，主持人David Ondrej与嘉宾Kun Chen进行了一场深度对谈 Kun Chen是一位曾在Meta、微软和Atlassian工作过的顶尖工程师，他开发了Firstmate来管理自己的AI编程助手团队，这一期他们主要围绕 Kun Chen极致的AI编程工作流展开，聊到了他如何用语音与主agent对话 [00:00:51]
Kun Chen：如何建立信任并处理复杂的决策，那我们就一起来听听这期的完整对话，我这边就是一个无边框的终端窗口，用的是WezTerm 我喜欢WezTerm 因为它高度可定制，基本上什么都能改，我现在开的是一个Herd会画 Herd有点像TMAX的现代版，我用了TMAX超过10年，最近才发现Hurder真的很喜欢，它管理终端里多个绘画的方式更现代，这个跑在我的Mac mini上，我还能用手机连上同一个绘画，对，所以我可以拿起手机通过SSH连上去，看到完全一样的终端窗口，这也是Hurder的一个好处，它理解agent是什么，为了做更多事，人们得同时管理好几个并行的agent绘画，对，对吧，因为一个agent干活可能要花不少时间，所以大家就开始多开几个绘画，有时候我看到有人开20 20 30个绘画，但后来我简直要疯了，因为，是啊 20个绘画，你得全记在脑子里，对吧，没错，对这个痛点促使我开发了Firstmate 因为我觉得这不可能是最终形态，我不想整天就在不同标签页之间切来切去，还得记住每个是干什么的，我开发Firstmate 是因为我觉得agent能力越来越强之后，应该能替我去处理这些事，我几个月前开始用这套方案做实验，它真的管用，所以现在大多数时候，我只跟这一个agent对话，好 Kun 你曾在Meta 微软 Atlassian [00:01:59]
David Ondrej：这些顶尖公司做过顶尖工程师，你现在的AI编程配置是什么样的，我现在基本上用AI来写所有我想做的东西，我几乎不会手动写任何代码了，顺便问一下，这个转变是什么时候发生的 [00:02:38]
Kun Chen：我觉得是个渐进的过程，一开始大概是三年前，我们有了GitHub Copilot 对吧，代码补全，我们起初只是接受一行的代码建议，然后它进化了，开始能给出多行代码，一次给出一整个函数，对吧，再后来，我觉得改变局面的一个拐点，是Claude 3.5 Sonnet的推出，那是个改变游戏规则的时刻，那是第一次，我觉得一个agent可以领一个任务，然后开始替我们做事，对吧，并且带着一整套完整的结果回来，所以我差不多就是那时候开始用agent的，那时间也很有意思，因为我当时在Atlassian工作，我的工作就是开发编程agent 所以我大量的试用那个模型，因为我当时我试过各种模型，从GPT 3.5开始根本不行，让它编辑一个文件都费劲的很 GPT 4好一点，但还是差那么点意思，真正改变游戏规则的是Claude 3.5 Sonnet 所以那是另一个拐点，过去三年里，这么几个拐点，真的极大的改变了我的工作流，那你能截个屏 [00:03:46]
David Ondrej：给我们看看你现在的配置吗，好没问题 David 你是终端档，还是图形界面档，我其实两个都用，真的，有几周我只用终端，比如CMAX 有几周我可能就用Codex应用
Kun Chen：或者Cursor的agent窗口，所以我是混合型的，好酷，我更偏向终端，我尽量把终端，作为主要的开发环境，我在上面积累了太多肌肉记忆，我这个配置用了超过20年，一直在终端里写代码，我觉得他给我养成的习惯就是，双手几乎时刻不离键盘 [00:04:10]
David Ondrej：对那些害怕终端的人，你有什么想说的，你知道他们可能不是开发者，技术背景没那么强，你会对他们说什么，一开始确实有个学习曲线，去适应这种不同的工作流，你得用键盘来控制
Kun Chen：终端里的所有移动和操作，所以刚开始，你会觉得生产力下降了，因为你不习惯，不确定怎么把每件事都做好，对吧，有这个初始阶段，但一旦你跨过去，它就能让你保持心流，因为你可以双手放在键盘上，用键盘快捷键之类的方式控制一切，你的思绪是唯一在流动的东西，太棒了，那带我们看看吧，我们这儿有PR agent 这是在做什么，我这儿就开着一个，无边框的终端窗口，用的是WezTerm 我喜欢WezTerm 因为它高度可定制，我几乎可以改掉它的一切，这里我就把它设成了无边框，没有窗口边框，什么都没有，就是一个纯粹的终端窗口，还带着背景模糊之类的效果，我喜欢它，看起来好看，这样工作的时候，眼睛看着也舒服，我现在开的是一个Hurder绘画 Hurder有点像T-Max的现代版，我之前用T-Max用了十多年，最近才发现HUDDER一下就喜欢上了，它管理终端窗口里多个绘画的方式更现代一些，那你试过CMAX吗 CMAX和HUDDER有什么区别，对 HUDDER更彻底的待在终端里 CMAX有一个Gucci框架，框架里面有一些面板是终端，但HUDDER完全就在终端里，这样做的好处是，这个终端窗口就只是一个正在运行的程序，它跑在我的Mac mini上，我可以用手机连上同一个绘画，我拿起手机，通过SSE连接，就能看到完全一样的终端窗口，一切都保持一致，用其他各位应用就很难做到，因为你没法直接远程桌面，体验也不会好，对我来说，这就是主要区别，明白了，我现在运行着一个HERDA绘画，在这个绘画里，左上角你能看到有Spaces 这个我待会儿再讲，它基本上就是HERDA里的工作区，你可以用它来组织工作不同的项目等等，左下角是智能体 这是HERDA的一个优点，他理解agent是什么，以前的终端附用器，像TMAX和Zalich 他们不太理解agent 他们理解你的终端窗口，标签页和面板，但不知道agent是什么，但Hurder知道，我这儿有个Pagent正在工作，这个工作状态，基本上告诉我，我不用盯着他看，他还在干活，不是在等我，这非常有用，对，在这个Hurder里，我用它来组织我的agent 让我能在所有，正在进行的绘画之间导航，这就是我喜欢它的地方，但大多数时候，我只在一个绘画里工作，就是这个Firstmate 这个工作流，大概是几个月前形成的，那时我意识到，自己一直在管理太多绘画，我觉得大家用Cmax 和其他编排类应用时也一样，为了完成更多工作，就得同时管理，好几个并行的agent绘画，对，对吧，因为一个agent干完活，可能要花点时间，所以大家就开始多开几个绘画，我有时候看到有人开 20 30个绘画，但后来我简直要疯了，因为20个绘画，你得全记在脑子里，对吧，你得记住，这个绘画是干嘛的，那个在做什么，对，这种痛苦促使我开发了Firstmate 因为我觉得这不可能是最终形态，我不想一整天都在标签页之间切来切去，还得记着哪个是哪个，我开发Firstmate 是因为我觉得随着agent能力越来越强，他们应该能替我处理所有这些事情，我几个月前开始用这套设置做实验，结果真的可行，所以现在大多数时候 Firstmate是我唯一对话的agent 我只跟Firstmate聊，让他替我管理所有其他绘画，我可以举几个例子，你看现在已经有事在发生了，对吧，他在做一些工作，告诉我无需操作，我现在想起之前有项工作进行到一半，就可以直接问，嘿，苹果审核通过我们这个APP了吗，那是我在开发的一个iOS App 提交了App Store审核，我不确定通过了没有，就可以直接问Firstmate Firstmate不会自己去查，他会把任务委派给另一个Crewmate 原因是如果Firstmate亲自去查，那他自己就忙起来了，对吧，就被站住了，我就没法再跟Firstmate说话了，你看现在Captain 我正在查这个，他已经叫另一个Crewmate去帮我查了，好处是我现在还能跟Firstmate说话，他不会被别的事卡住，我可以再问点别的，我记得Treehouse 有几个不错的PR 等着我审查，你能查一下吗，所以Firstmate 能访问他负责的所有项目，对，他是所有事情的协调者，知道我所有的项目，我后面也会聊到一些，扩展性的问题，但基本上，我大概有20到30个，公开的GitHub仓库，都挺受欢迎的，人们会给我提issue和PR 如果要我手动去处理，这二三十个项目，我肯定会疯掉，所以我基本上，让Firstmate替我管理，所有项目，所以当我说Treehouse Firstmate就知道是哪个项目，我主要的问题是，你是怎么建立起足够的信任，把这么多责任，都交给Firstmate的，信任是需要时间建立的，对吧，我一开始也不是什么都信任他，我最初是把他当原型来玩的，然后慢慢让他帮我，做越来越多的事，同时观察他做的怎么样，刚开始的时候 [00:09:19]
让 Firstmate 成为唯一入口
Kun Chen：刚开始的时候，尤其是最早那会儿，问题还挺多的，比如他没把任务，分给合适的组员，或者让好几个组员，做同一件事，互相冲突诸如此类，我就不断优化这个过程，最后终于掉到了一个很舒服的状态，可以直接让Firstmate帮我处理所有这些事，而且再也看不到什么错误，或者不合理的任务分配了，所以现在他也启动了一个任务，去审查Treehouse的一些PR 然后我可以继续跟他聊别的，任何我想做的事，还记得之前我们在优化Firstmate的工作区组织吗，现在进展到哪了，我就可以这样不停地问，这些脑子里冒出来的事，现在这种感觉真的很好，我最享受的就是，我始终处于一种，大脑清空的模式，我有了想法，就直接导给first mate 让他去处理剩下的一切，我完全不用操心，他需要经过哪些步骤，才能把事情做完，那你会不会进到具体的子agent里，看看他们在做什么，还是基本不看，现在很少了，一开始开发first mate的时候，我经常看，就是为了观察嘛，看他做的对不对 first mate的沟通效率高不高，有没有把上下文准确的传给组员，所以早期我自己做了很多观察，但现在不怎么做了，不过有时候我还是会觉得，怎么搞了这么久，有点像在真实的公司，真实的团队里工作，有时候经理还是会直接去找下属，对吧，可能绕过技术主管，就因为有时候直接沟通效率更高，所以如果我想这么做，我可以在herd里调出一个视图，这个视图基本上能让我，跳到任何一个agent绘画里，我直接跳过去就行，这个很棒，然后看看那边到底在发生什么，对，这个非常非常好，对，你看这里 Firstmate回答了我上一个问题，这是一个很重要的设计节点，好吧，我前阵子跟Firstmate讨论过一个想法，但我们没有继续往下实现，因为我对这个方案不太确定，总觉得哪里不对劲，我给你看个东西，像这种技术设计，有时候会有点复杂，对吧，牵扯的环节很多，有权衡，有优缺点，所以这种情况，我通常会用Lavish 一个交互式的HTML Artifact 来帮我更直观的理解，这个想法和其中的权衡，我现在就试一下，你能用Lavish 跟我一起审查一下 Herd工作区的设计吗，这个操作会让Firstmate 创建一个HTML Artifact 把我们面临的设计决策，用可视化的方式呈现出来，这样我们协作起来会更容易，对，他正在用Lavish XE 来做这件事，创建Artifact 可能需要一点时间，现在他正在用HTML写设计审查，我们应该很快就能在浏览器里看到了，所以你现在是用5.6做你的主agent 为什么选他，对5.6在XI上，就是我的first mate 关于first mate 我学到的一点是，他需要处理大量的上下文，他得理清很多不同的事情，比如我现在在说哪件事，当我说Header工作区试图设计时，他得知道，我们前阵子做过这个，我指的是那个，所以Firstmate 其实需要很强的推理能力，它必须能理清，所有这些复杂性，然后我对不同的组员，有不同的规则，当Firstmate给组员派任务时，它有一套，我告诉它的偏好设置，它会用这些偏好来分配任务，你看这个文件，就是我写规则的地方，这些规则会告诉Firstmate 什么情况下，该用哪个agent 用哪个模型，以及用多高的推理强度，之前这里有一条规则是，对于任何高复杂度的技术设计和产品设计，在Claude Code里用Fable 我觉得Fable有我很喜欢的深度和创造力，所以对于那些非常复杂的设计，我喜欢用Fable当组员，但默认情况下现在用的是5.6 纯粹是因为订阅方案的实用性考虑，我可以给你看，我有个东西在追踪我的配额，我的Grok配额用完了，正在等重置，我这周的Fable配额也快用完了，离重置还早着呢，所以我在省着这剩下的Fable配额，留给那些我真正非常需要Fable才能做的事，我们订阅拿到的这些大模型配额，根本就不够用，我觉得我会建议大模型公司 [00:14:19]
David Ondrej：认真考虑推出更高等级的套餐，对 500 因为现在200美元这一档根本不够用，我完全同意，我知道这么说肯定有人不爱听，但我们确实需要500美元那一档，对
Kun Chen：所以你从来不用API按量付费，对我觉得对个人来说，用API按量付费不划算，真要按API价格算，我过去一个月干的活，费用肯定超过1万美元了，根本撑不住，我觉得还有一个办法，也许能帮上忙，像GPT 5.5 5.6 还有很多云端模型，都有快速模式，对，对吧，快速模式基本就是，多花钱换DN持，我想要的反而是反过来，我想要更慢，但更便宜的模式，因为有太多任务，是那种后台任务，我根本不关心，它是不是很快完成，对吧，我关心的是，我总共能干完多少活
David Ondrej：因为现在，我的总额度才是平静，所以我希望他们最终，能开发出这样的东西，对，这个需求肯定有，不同的任务，需要不同的工具和设置，对吧，比如你再赶一个东西，十分钟后，有个非常重要的会，手头有上周的会议记录，那你需要快速模式，但如果你只是派一个agent 跑一晚上，那你就需要最慢最慢的模式，你根本不在乎，他每秒跑五个token 你只希望他把活干完，对就是这样 [00:15:36]
Kun Chen：我觉得整个光谱理想情况下，这些选项都应该给我们，让我们自己去做取舍，这就要回到我之前问的，那个关于Hurder 怎么组织的问题了，先交代一下背景，这个想法是关于Firstmate 怎么用Hurder 来组织他的Crewmates 现在所有东西，都像是一个扁平的列表，有时候很难搞清楚，哪个Agent干什么，所以就有人提出来，能不能组织得更好一点，你看这里，他基本就生成了，这个设计评审Artifact 他给了一个推荐方案，不过我来带你过一下实际的提案，对这就是我们现在的层级结构，他用了这种竖状图，对吧，来给我展示这是什么，这非常有用，不然的话，我们通常只能在终端里跟agent讨论，然后agent就会打印出一大长串文字，对吧，对，但在这里我就能很直观的看到，这是一个竖状结构，这是他现在的样子 NativeNow Report Tree和Work Tree的层级，对，不同的Work Tree会按代码仓库来分组，然后这里有一个推荐的架构，这个也很酷 lavish能让agent直接生成一块白板，这是一块生态白板，我基本上可以直接看到所有的图表，我还能调整它，我可以直接说这里不对，然后把框移来移去，再把反馈发回给agent 在这些artifact上能做的交互非常多，这就是我特别喜欢用这种基于lavish的工作流的原因，到最后它通常会指出我需要做的决定，它还有一些不确定的开放性问题，所以他给出了几种方案，对吧，我需要选定一种，我想优先考虑supervisor 归属这个方案，因为按supervisor来分组，逻辑会更顺，这里上下文信息太多了，我可能不会在这上面，花太多时间，但我会把这个决定标记出来，然后发回给agent 就这样基本上，做这种决策的工作流，就是这样，那核心问题就是，像你说的，这些不同的项目，上下文信息太多了 [00:17:51]
David Ondrej：你都很熟，那你怎么还能做到那种深度工作，怎么还能进入心流状态，而不被搞疯，就算有了这套设置，你还是可能同时开太多东西，然后就会想，那个项目怎么样了
Kun Chen：那个agent又在干嘛，你是怎么做到深度工作的，大多数时候，你想想我在这次绘画里，花在firstment上的时间，基本都花在了那些模糊的决策上，所以我并不是在不停的切换标签，或者担心，嘿那个活还在跑吗，那个是不是在等什么东西，这些事我不用操心，我唯一花时间的，就是那些真正模糊的决策，那些真正需要我来判断的事，所以基本上，我整天在做的，一个是把我的想法，全部倒给first mate 所有我想做的事，我就直接告诉first mate 我想做，然后我就可以把它忘了，他要么会自己做完，要么会作为一个带决策的问题，回到我面前，这是我做的一件事，就是把我所有的想法，都告诉first mate 另一件事就是处理那些，我必须做，但Firstmate自己决定不了的决策，我其实给Firstmate 写了很多指令，告诉他什么时候应该回来找我，因为这一点要调对，其实非常难，有时候我们会看到 Agent直接放飞自我，在你没盯着的时候，自主干了一大堆事，到最后你才发现，他做错了，我觉得这一点，是我们真正需要去调整 Agent的行为的地方，去找到那个最佳平衡点，而且每个人，可能你对这个点的偏好，会稍微有点不一样，所以这是需要我们跟自己的Agent 好好聊透的一件事，用这套设置，你一般一天要跑多少token 我倒没算过token数，我主要看的是，我用掉了额度的百分之多少，明白了，现在我会尽量保持一个不错的平衡，你看到我把Claude的额度用光，而且用的比正常快很多 [00:19:03]
David Ondrej：原因是Anthropic告诉我们，哦对 Fable要下线了，是啊，我甚至公开说过他们，我说这是在玩什么幼稚游戏，要么就留着，要么就删掉，别搞这种每周延期，你懂吧
Kun Chen：或者像OpenAI那样，给我们存起来的重置次数，对吧，对，这样我们就能自己控制了
用语音和可视化工具协作
Kun Chen：这样我们就能自己控制了，所以情况挺惨的 Cloud的额度快用完了，好像还有几个人进医院了，你看到那个新闻了吗，因为他们连续熬了两天，以为Fable要没了，结果直接进了重症监护室，是啊，说到透明度，我觉得这是Anthropic 一个很大的问题，他们每次跟开发者沟通，还有过去处理很多重大变动的方式，就是不够透明，也没给大家足够的确定性，来做决定，这算是我随口吐槽一下，不过，我通常就用这个，来盯着自己的额度，尽量保证，消耗速度，跟重置周期匹配，好，用OpenAI的时候
David Ondrej：我可以稍微激进一点，因为我有几次，重置机会可以用，而且他们给的，重置次数非常多，但你没发现 GPT 5.6骚特别烧额度吗，尤其是在 Extra High或Ultra模式下，至少头一两天 [00:20:35]
Kun Chen：或者头24到48小时，是这样，这里面有几个原因，头几天 OpenAI出了个错，他们把5.6的上下文窗口压缩预值，调到了372k token 对吧，后来他们发现，任何超过272k token的请求都会被多收费，哦，所以很多人token消耗的比正常快，他们为此做了一次重置，所以我觉得他们正在修，但这是大家觉得5.6烧token比以前快的原因之一，另一个有意思的点是 Ultra是个特例，对，我觉得Ultra和Claude的Ultra Code 对吧，对，他们不一定是一个推理努力级别，只是子agent 他们是一个提示词，告诉agent要激进地使用子agent 对吧，去把任务分发出去，而且有一段时间，可能现在也还是这样 OpenAI Codex在用Ultra的时候，会启动特别多的子agent 而且每个子agent都是Ultra agent 这烧token的速度就太快了，我觉得X-HIGH和HIGH就很不一样 XI不会让我的Token烧的那么快 XI其实是我的最佳选择，因为虽然它叫XI 但速度其实相当快，好的，我们刚才聊到的那些提示词，通常返回结果都很快，说到这个 [00:21:41]
David Ondrej：昨天我正好跟一些人做了测试，我观察到他们在跑5.6LUNA 我当时就想，怎么这么慢，他们切换到5.6M之后，速度就快多了 [00:22:05]
Kun Chen：所以我不知道OpenAI那边是什么情况，但现在Luna确实比Soulman 对你知道为什么会这样吗，这里有个基准测试，我可以给你看，叫DeepSui 我猜你可能也见过这个吧 DeepSui 这大概是我目前最信任的基准测试了，对因为它还没被污染，它足够新训练数据里还没有这个，所以也许最终它也需要更新，但现在我非常信任它，你可以看到，这里有几个很有意思的异常值，看Sonic 5 从Low Medium High 一直到F's High 它的曲线都挺合理的，对吧，这张图是左边更贵，上面更智能，所以右上角是最好的 Sonic 5一直到F-Side都很合理，但如果你开到Max 你看它就疯了，它是所有模型里最贵的 Sonic 5比Fable还贵，对，所以我觉得出现这种情况的原因是，当模型本身不够聪明的时候，它就会浪费大量计算周期，去做错误的事情，尤其是你让它做Max Reasoning的时候，它会非常努力地思考，但还是不够聪明去解决问题，所以它只会浪费大量时间和token 我觉得Luna也是一样的情况 Luna的独特之处在于它的曲线非常陡峭，意思是它从非常非常低的智能，一直延伸到非常高的智能，所以我觉得Luna很可能也有类似的情况，就是你让它去解决一个难题，它解决不了，但会浪费大量token去尝试，对我观察到的正是这样，它会做太多工具调用，来完成一件相对简单的事，然后5.6骚用medium大概一分钟就搞定了，没错，所以我现在这场任务基本只用soi 我可以调整soi的推理级别，对吧，我找不到什么理由去用terra 因为我能直接把soi的推理级别调低，为什么要用terra呢，这样我能用更低的成本，得到一个更聪明的模型，不过我在某些情况下会用luna 比如在我的家庭住手上，我有一个家庭住手在运行我的房子，我可以控制灯光和所有东西，音乐播放器等等，那个我用Luna 因为它快，我需要它非常非常快，那为什么不用个开源模型来做这个呢 [00:24:04]
David Ondrej：比如Kimiki 2.7 Code 在Open Router上，用带Nitro后缀的版本，你可以跑到每秒两三百个Token 对对，开源模型的话，有几种方式可以搞，一种是本地跑，其实我觉得
Kun Chen：像这种家庭助手的场景，我完全可以在我的Mac mini上，本地跑一个，效果应该也还不错，对吧，但问题是，我的Mac mini现在是非常宝贵的资源，因为我所有其他事情都在Mac mini上做，我有很多任务要跑，我构建IS应用，做其他所有事情，都会消耗Mac mini的算力，我把手机连到它上面，把所有东西都连到它上面 Mac mini就像我的个人算力中心，有道理，如果我在上面跑一个开源模型，它就会跟我做的其他所有事情，抢资源，所以这是一个限制，我也可以通过云服务商，来跑开源模型，对吧，但我发现省下来的那点成本，还不足以让我真的从Luna这样的东西切换过去，明白了，对，所以到目前为止，我还没有真正深入去搞本地大模型和开源模型，那在agent harness方面 PI是你目前最喜欢的吗，对，我现在用几个不同的harness 目前我在用PI 因为我今天主要在用GPT 5.6 因为配额的关系，但我现在的做法是，如果我用anthropic的模型，我就用Claude Code 因为他们把其他都精了，如果我用GBT 5.6 我就在PI里用，原因是Codex CLI 作为Harness不是那么好，它有一些优势，比如它开箱就集成了，图像生成功能，这非常方便，但很多其他能力，比如管理后台进程，就没那么好，它缺少很多，能让CLI体验，真正顺滑的功能，跟PI比起来 PI的可定制性非常高，是的，所以我想实现的任何东西，基本都可以自己写个插件来实现，这就是我选择用PI 而不是Codex来跑GPT模型的主要原因 Grok是我用的另一个模型，因为我已经订阅了X 里面有一些配额，我其实觉得Grok 4.5非常好用，是啊，但我在欧盟，所以你知道我用不了，因为它在欧盟被禁了，好吧，那太可惜了，不过对，这确实是个很不错的模型，我对Grok 4.5的看法是，它就像是开了快速模式的OPUS 我去，对它基本上能干OPUS 能干的任何事，而且速度超快，用Grok还有一个有意思的地方，尤其是在Grok Harness 也就是Grok Build Harness里，它好像会给你免费的XAPI访问权限，让你能读帖子和搜索东西，不然这些是要花钱的，因为XAPI是收费的，所以这是另一个好处，我可以用Grok Build来帮我搜推文，梳理新闻之类的，我觉得他也是进步最快的Harness之一，对吧，对对完全同意，他还很年轻，对吧，他非常新，而且他们也是最近才开始认真对待这件事，但他已经在一些后台进程轮巡等方面，比Codex做得更好了，明白了，那你还用其他Agent Harness吗，我也经常用OpenCode OpenCode也很流畅，我很喜欢他的2E体验，不过我觉得随着时间的推移，我开始越来越多的倾向于用PI了，因为PI可以更深度的定制 [00:27:19]
David Ondrej：你几乎可以改变PI的每一个方面，我挺喜欢这点的，所以你非常看重可定制性，对吧，那你觉得未来会不会有越来越多的人，拥有自己的专属设置，而不是用那些预先定义好的
Kun Chen：打包好的应用，我觉得很可能会有不同的偏好光谱，我认为会发生的是会有一群人，他们对事情该怎么做，没有太多自己的主见，他们会去寻求别人的帮助，比如别人给他们一套验证过的打法，所以他们只想要一个开箱即用的东西，他们不想整天为捣鼓这些东西操心，我觉得这类人会一直存在，这挺好的，人们会为他们开发工具并发布出来，这样他们就能直接用那些开箱即用的东西，还会有另一群人，他们会开始对事情该怎么做，有越来越多的个人偏好，这些人就需要那些，真正能被深度定制，和不断进化的东西，我之前给你看了一个东西，就是我菜单栏上的，那个配额小部件，还记得吗，记得，这个东西，我叫它baby menu 这是我自己做的，而且它可以自我修改，你现在能看到，它上面有一堆东西，这些功能绝不可能，同时出现在一个产品里，有我的GitHub统计数据，对吧，还有CPU和内存占用，然后还有我的Cloud 和Codex配额，没人会做一个这样的产品，然后卖给其他人，这是属于我自己的东西，至于我为什么把它弄成这样，我是通过跟baby menu对话来实现的 baby menu一开始是个空的东西，我告诉他我想要什么，他就会自我修改，然后慢慢变成现在这个样子，我认为这就是未来很多软件，会呈现的一种形态，他们会提供一个开箱，寄用的合理的体验，但现在每个人都有agent了，所以每个人都应该能，跟自己的agent对话，来定制他们使用的软件 [00:28:48]
David Ondrej：而且还会出现很多自我修复的循环，你知道很多软件都会有一个方便报告bug的途径，然后就会启动一个像Codex CLI这样的东西，去实现修复，再提交一个PR 你再用像CodeRabbit这样的工具去审查它，这个bug可能20分钟内就修好了，完全不需要人参与，对对完全正确，还有一件很有意思的事情正在发生，就是Firstmate Firstmate [00:29:35]
Kun Chen：基本上就是一个agents.md文件
把 Agent 系统做成可扩展的软件
Kun Chen：基本上就是一个agents.md文件，这个agents.md文件规定了Firstmate应该如何行动，如何在一大群crewmates之间协调不同的任务，这就像是给Firstmate的指令，它还有一些脚本文件，在这个binary文件夹里有一堆bash脚本，这些bash脚本基本上处理了很多Firstmate 本来需要一步步去执行的确定性步骤，把它们打包成bash脚本，这样Firstmate就不需要花token去走完那些确定性步骤了，这样做的好处是agents.md和这些bash脚本都在当前目录下，所以Firstmate可以修改它们，对吧，有一件很有意思的事，我甚至都没意识到会发生，就是当Firstmate出了个bug 导致它没法正确的做某件事时，它会自己绕过这个bug 所以现在这个软件几乎是不可阻挡的，你没办法阻止Firstmate去做它需要做的事，即使这些脚本里有各种各样的bug 也顶多会让Firstmate的效率变低一点，但不会阻止它继续工作，这和传统软件相比，是一个非常大的变化，对吧，在传统软件里，如果有bug 那就是个bug 它可能会让应用崩溃，让你完全没法用下去，但现在我们有了这种智能软件 [00:30:51]
David Ondrej：它几乎总是很灵活，你很难写出一个，能阻止它工作的bug 所以基本上挑战就变成了，我们人类在哪些环节，拖慢了agent的速度，以及我们怎样才能把自己，从尽可能多的环节中抽离出来，只参与那些真正重要的环节，对，对完全正确，关于你的这套配置，还有什么大家应该知道的吗，我觉得可能还有一点，就是no mistakes 我经常遇到这种情况 [00:31:15]
Kun Chen：让AI帮我生成代码，对吧 Fable和5.6写代码非常快，质量也很高，能做很复杂的改动，但问题是，如果AI做了一个复杂的改动，我怎么知道能不能合并呢，对，我给你看一个真实的例子，我打开另一个项目 Hybrid 这是我给孩子们，做的一个AI agent的工具，让他们学着用agent 我刚做了一堆改动，你看这个diff 是我昨天用fable改的，现在这些改动就放在这，我该怎么办，一行一行去审查这个diff吗，那太花时间了，对吧，我们的时间真的很有限，如果我去审查AI生成的代码，那我每天能完成的工作量，就有上限了，对吧，基本上就取决于，我每天能审查多少代码，而不封掉，所以现在我的做法是，把这些改动全部发给NoMistakes 它会跑一套流程，做对抗性审查和验证之类的，然后给我一个结果，让我更容易判断代码有没有问题，我的操作就是输入NM 这是NoMistakes的缩写加一个Y 意思就是把当前工作目录里，所有的代码改动放到一个分支上，交给NoMistakes处理，我跑一下给你看 NoMistakes会创建一个分支，让agent帮我建分支，做提交，把所有必要信息放进去，然后把这个分支，推到一个本地Git代理里，在一个隔离的工作数里做验证，我们一会儿就能看到，好，提交已经创建好了，这就是No Mistakes的流程，它首先会分析意图，它理解意图的方式，是去分析，产生这次改动的agent绘画 agent绘画就是，我跟Fable一起做，这次代码改动的地方，对吧，我在那里输入了提示，最初表达了我想做什么，所以第一步就是，理解那个意图，因为那才是应该，被遵守的真正需求，是我说过我想要的东西，他理解了意图之后，会在最新的远程主分之上，做一次遍机，这样我们后面，就不会遇到合并冲突，现在他正在做对抗性审查，这里他用的是 GPT 5.6 SODE中等模式，来审查改动，如果发现了问题，非常明显的bug 它会自动修复，不够明显的，就会升级给我审批，如果涉及产品层面的影响，有时候我们发现一个bug 修复方案会要求改动产品本身，对吧，这种情况，我是希望自己有发言权的，我设了一些规则，规定这种情况要升级给我，我们也许能看到，它是会自动完成，还是会升级什么，基本上这个审查步骤，会持续一段时间，它会抓住几乎所有边界情况 bug和遗漏的东西，最后在对抗性审查结束后，它还会做测试，测试会产生一些可见的证据，能真正告诉我，代码确实按预期在运行，然后是文档代码检查，接着他会推送PR 并一直盯着CI流程，直到PR变绿，然后他会告诉我，好了，现在你可以去看看了，所以通常我启动no mistakes之后，就不会再看这个界面了，我会走开去做别的事，现在我甚至都不自己启动no mistakes了，我让Firstmate去做，是Firstmate在帮我启动这个，总之我觉得这个东西帮了我大忙，因为如果没有他 no mistakes抓到的所有问题，都会让我的代码库变得一团糟 [00:34:25]
David Ondrej：但在大型项目上，它不会烧掉太多额度，太多token吗，这让我想起Vercel的DeepSuite 它会有很多警告，说如果你在大型代码库上跑这个，会烧掉几万美元的API额度，因为它挖得太深了
Kun Chen：你是怎么在审查次数和消耗之间，做平衡的，对好问题，我觉得有一个方面是，追求质量必然有成本，你想想一个软件团队，如果我们去掉，人与人之间的代码审查流程，每个人都能更快地合并代码，对吧，但之后就会出现各种质量问题，生产环境会出各种事故，最终你还是得用另一种方式付出代价，对，所以这部分是不可避免的，我觉得我们得做个权衡，我们对某个项目的质量，到底有多在意，有些项目，比如周末搞个展示用的demo 质量其实没那么重要，对吧，这种情况我们可能就不用跑，这种很重的验证流程，但如果是做生产环境的软件，会影响很多用户，甚至有客户会因为体验被搞坏，而停止付费，那我们就得小心了，所以我觉得在哪些项目上，用这套方法是需要权衡的，另外我也不会把每一个改动，都送进这个流程，有时候我只是做个很简单的修复，对吧，对，我很有信心它不会搞出问题，我可以自己判断一下，说这个改动直接合就行，对，所以也有这种情况，但绝大多数改动还是会走这个流程，我可以给你看看我的数据，我有个no mistakes的统计，我会追踪所有发给no mistakes的改动 [00:36:02]
David Ondrej：我设了一堆技术器，帮我了解这些改动的情况，这也是AI特别棒的一点，你可以衡量很多以前很难衡量的东西，多亏了agentic engineering 你可以开始追踪你工作的几乎一切
Kun Chen：对这点说的特别好，如果是人类追踪起来就难多了，比如我有一百个人给我干活，我想知道他们做的每一件事，这很难，对吧，除非我是马克萨克伯格，会把所有东西都录下来，但用agent的话，一切都可以自动化，我们可以统计所有东西，这真的很棒，这就是我的no mistakes 数据大概是过去三个月左右的，总共1000个改动，跨59个仓库
David Ondrej：其中63%的改动都被抓到了错误，那你觉得原因是什么，如果让你猜，是流程的哪一部分最有效，是不同模型做的对抗性审查吗，对你看这个，哦，不错 [00:37:07]
Kun Chen：对按步骤看修复情况，审查这一步发现并修复了最多问题，我注意到好像是从GPT 5.5开始 GPT模型在抓边缘情况上变得特别强，我比较过几个模型，最喜欢用GPT做审查，它非常细致，特别擅长识别那些，在罕见场景下可能发生，但确实会发生的问题，所以GPT这种对抗性审查，在抓这类问题上帮助巨大，另一个大头是文档，我经常发现，我做了改动，或者agent做了改动，但他不会去更新比如readme文件，里面还写着一些过时的内容
David Ondrej：跟我们做的改动冲突，对吧，这些情况全被这一步抓到了，真的很有用，非常好，看到这种高级配置，我想到一件事，就是我观众里有很多人，把所有时间都花在搭环境上了，对吧，他们搞了一套超复杂的agentic engineering配置，但从来不发任何东西，你是怎么让自己保持理性的，比如可能只花10% 20%的时间去改进配置，写脚本搭系统
Kun Chen：剩下的时间真的在用它们做产品，对这个话题特别好，因为我自己几个月前也在这个问题上挣扎，所有事都要花时间，当我做东西遇到阻力时，我就想做个工具来消除这个阻力，但做工具本身又会占用我的时间，对吧，然后工具会出问题，我又得去修，有那么一小段时间，大概一两周，我发现自己基本全在搞工具，没在做真正要做的东西，这个情况在我开始用Firstmate之后改变了 Firstmate的好处是，那些琐碎的事，比如修bug 或者我遇到一个问题，只需要改进一下，我根本不用花什么时间，我只需要跟Firstmate说，有个问题他就会去修，真正占用我时间的，会自然转向那些更有趣，更模糊的决策，这些往往是新产品开发，所以现在有了Firstmate 帮我处理这些琐事，我就有更多时间，去做我真正想做的产品，比如Hybit和我的iOS EPP 这是我开始用Firstmate之后，一个无心插柳，但自然出现的结果，对，我喜欢你配置的一点就是 [00:39:17]
David Ondrej：看到很多东西，其实是从真实问题里长出来的，这让人耳目一新，因为AI圈里，有很大一部分人做事，只是为了做而做，就像我把这个和那个连起来了，或者我搭了这么一套，看他多能跑，看他能跑多少个agent 但这并不是从第一性原理出发，不是因为他们需要完成工作，就只是觉得，哇，让这200个reagent并行跑，不是很酷吗，但听你讲下来
Kun Chen：我能看到每件事背后的理由，对对
独立开发与软件的重建
Kun Chen：对对，这绝对就是我的做法，一开始，我其实根本不想做这些工具，就在三个月前，我刚从大厂辞职，出来单干，我本来的打算是做几个，我觉得有潜力的C端应用，比如给小孩用的AI家教之类的，我有几个特别想做的点子，计划是把所有时间都花在开发这些应用上，单干和在大公司工作，有个很有意思的区别，在大公司有很多其他的瓶颈会拖慢你，你得花时间开会跟别人协调，我做到了比较高的级别，结果就是我所有的时间都花在告诉别人该做什么，而不是自己动手做，所以我现在单干，用agent来跑任务，完成工作，就不会有这种瓶颈，单干的时候，除了你自己，没有别的瓶颈，所有事情的瓶颈，都在我自己身上，在我自己的工作产出上，于是我就开始遇到各种问题，怎么验证AI生成的代码，怎么跟AI更互动的做规划，而不是盯着终端里，一长串的文本，怎么同时处理，二三十个绘画而不疯掉，我开始碰到这些问题，然后就被迫去开发这些工具，因为没有别的办法，能很好地解决它们，结果我好像一不小心，就成了开源项目的维护者，现在我还得处理，开源项目的问题和PR 这挺好的，能让工具变得更好，但现在我得平衡我的时间了，到底花多少在开源维护上，花多少在我原本计划，要做的那些应用上，明白了，好问个宽泛的问题，你觉得哪些类型的软件会变，哪些会留下来，对对这个问题问的真好，我觉得有几个大趋势正在发生，一个是很多软件，特别是过去20年里做的那些SaaS软件，大部分都是为人设计的，他们本质上就是一个给人用的界面，后面接个数据库，再配一套还算可扩展的系统来管理，我觉得给人用的这部分界面，基本会消失，我们其实不想自己去点遍所有网站，像Salesforce还有那些SaaS网站，大多数时候，我们想让我们的agent 去跟这些服务打交道，而agent需要一套，不同的接口来工作，所以我觉得这些服务，会迎来一次重建，一次非常大的重建，让他们变得更无头，去掉给人用的那部分界面，或者说把给人用的界面，改成让人能和AI 协作完成任务的东西，所以我觉得会有一场大重建，那些能给agent提供，非常好接口的软件，让agent能非常高效地，跟这些服务协作，我觉得这些会留下来，所以现在，如果我们想想新一代的，类似GitHub的东西，我觉得不管谁最终胜出，成为新的GitHub 都必须把这一点做好，它需要是一个 agent可以操作的无头服务，而不是一个 [00:42:42]
David Ondrej：需要人去点击浏览的网站，那这具体是什么样的，是更好的文档，还是稳定的API模式，对agent来说，真正重要的是什么，对，对这个也很有意思，我给你看个网站，叫XE.MD
Kun Chen：其实这是我开始给agent做工具时，才深入研究的东西，我发现很多工具，包括mcp服务器和CLI人们开发出来，但并没有真正为agent优化过，拿mcp服务器来说，我觉得很多公司还在学习，怎么给agent开发真正好的接口，结果就是，有些mcp服务器效率真的很低 GitHub 我可能要直接点名了 GitHub的mcp服务器，可能是市面上效率最低，也最没必要的MCP服务器，因为GitHub本身就有很好的CLI Agent 用GitHub CLI就能完成大部分工作，我们为什么还需要一个MCP服务器呢，我实际跑了很多基准测试，我看看能不能找到那个GitHub的基准测试，就在这儿，我跑了个基准测试来评估同样的任务，如果只改变接口，影响到底有多大，这里我们可以看到，如果我们用GitHub CLI 这是GitHub 衡量的是GitHub操作，如果用GitHub CLI 这是平均成本，如果用MCP服务器，有几个变体，不带工具搜索的，带工具搜索的，带代码模式的，但完成同样的工作，它总是比CLI更贵，这就是GitHub操作的情况，这些基于MCP的方法更慢，需要更多轮交互，消耗更多Token 在各方面都更差 GitHub CLI优化得更好，也更好用，我想可能是因为，它存在很久了，大模型的训练数据里，已经有大量如何高效使用它的例子，所以它本来就已经很好了，我觉得对GitHub操作来说，除了某些服务器之间的集成，基本没有理由去用MCP CLI的问题在于市面上，大多数CLI都是为人类开发场景设计的，是人在跑那些CLI 所以我觉得这里大概还有改进空间，于是我给Agent开发了一批CLI 并且开始真正提炼出几条原则，能让CLI对agent来说极其顺手，我的证据就在这里，除了GitHub的基准测试，我还按照自己总结的，对agent友好的CLI原则，做了一个AXIE 它甚至能比GitHub CLI更便宜，成功率也更高，这是一个例子，我还给Chrome DevTools 做了一个，因为浏览器自动化，也是一个非常非常普遍的用例，对吧，很多人用agent跑浏览器，去做各种事情，所以我给几种常见的，把浏览器连到agent的方法，都做了基准测试，有Chrome DevTools MCP服务器，这个很流行，还有Agent Browser Dev Browser 类似这样的几个工具，我按照自己定义，并不断迭代的那些原则，做了一个Chrome DevTools AXIE 遵循这些原则，我写了一个封装，这个Chrome DevTools AXIE 就是对Chrome DevTools MCP的封装，所以功能上没有任何区别，它做所有事情的方式都一样，底层就是那个MCP服务器，我只是改了接口，现在它的效率就高得多了，平均成本降低了超过20% 什么都没损失，延迟也改善了很多，这就是浏览器这个用力的情况，我真正提炼出来的原则一共有10条，我整理成了文档，大家都可以去XE.MD这个网站看，它就是一套公开的标准，第一条是用Token效率高的输出格式，很多MCP服务器和CLI工具，他们用JSON来输出数据，对吧 JSON在你有别的东西，需要按结构化方式解析数据，是非常有用，但大语言模型agent 不是那样解析数据的，对吧，他们只需要理解数据的内容和语义，所以用token效率高的输出格式，一上来就能省下大量token 然后是尽量精简默认的schema 有些CLI工具，你问他要一点数据，他会把每一列，每一个字段都给你吐出来，类似这样各种问题，我把它们整理成一套原则，能让一个接口对agent来说真的很好用，靠着遵循这些原则，我就能持续做出封装和工具，让他们比原来的版本对agent更高效，我在这边发布了几个，这里也有一个目录，我有GitHub Axie Chrome DevTools Axie Lavish本身也是一个Axie 我最近还发布了一个Quota Axie 可以把agent的配额数据，暴露给你的agent 这是为了让Firstmate能聪明一点，别去用一个配额快用完的，订阅里的Crewmate 然后社区也贡献了一堆AXIE了，有NPM SQLite 很多我们常用的工具，都已经有了AXIE版本 [00:47:33]
David Ondrej：所以我绝对推荐那些，正卡在Token效率瓶颈上的人，开始考虑用更高效的工具，天哪这太棒了，我要把我所有的软件，都跑一遍这个，确保它们是Agent的原生的，对这个我能聊上几个小时，让我从产品层面问一下，我觉得咱俩大概都同意，很快99.9%的软件和工具，都会是agent在用，再说一遍，我们会跟自己的主agent对话，不管我们给他起什么名字，对，为什么还有那么多人，没意识到这点，因为还有很多人，他们关注的还是，我要做一个给人用的，原生网页界面，他们完全不去想后端，完全不去想命令行，你是在哪个瞬间意识到 agent会运行所有软件，而我们只需要跟自己的，主agent的对话就行了，这个问题问得好，我觉得这其实是一个学习曲线的问题，每次出现新的技术变革，我们都会看到同样的规律
Kun Chen：历次工业革命都是这样，蒸汽机刚出来的时候，电力刚出来的时候，互联网刚兴起的时候，一开始总是只有一小批早期采用者，他们就是纯粹喜欢捣鼓，就是喜欢玩技术，哪怕这技术暂时还看不到回报，我觉得我们现在就处在这个阶段，很多领域的捣鼓确实还看不到回报，还有很多遗留项目AI能帮的忙很有限，它确实能帮上一点，但提升幅度远不如从零开始的新项目那么大，对吧，所以那些领域的人试了AI之后，会觉得好像也没那么有用，我干嘛要花功夫去认真用呢，这些想法是有道理的，但这也解释了为什么早期采用者，通常都是那些纯粹为了玩而玩技术的捣鼓者，但正是这些人会摸索出真正管用的东西，正是这些人会摸索出工具，找出差距，找到真正能从新技术中获益的工作方式，然后这些人会开始把这些工具和产品分享给别人，这需要时间，早期采用者要真正证明某个东西好用，需要时间，他们要把这些经验提炼成别人也能用的好工具，需要时间，别人要被新工具说服开始花时间去用，也需要时间，所以这一切都需要时间，我觉得指望一夜之间，所有人都意识到同一件事 AI来了，一切都会这样改变，这不现实，我觉得每个人处境不同，各自的约束条件，每天做的事，手头的项目等等，都会决定他们什么时候跨过那个拐点才最合适 [00:49:21]
David Ondrej：我觉得用这个观点来收尾太棒了，库恩我完全同意
开源工具与社区
David Ondrej：库恩我完全同意，非常感谢你抽出时间，大家主要应该去关注哪些东西，可以去看看我的GitHub 上面列了很多开发和分享的工具，我基本上把所有东西都开源了
Kun Chen：我工作流里所有帮我提高效率的东西，都已经分享在我的GitHub仓库里了，我还有一个YouTube频道，做了一些视频，完整展示，我是怎么编程的，怎么用我开发的工具，来高效构建新东西，这些也是很好的资源，这几个可能是比较好的起点，如果你在用这些工具时，遇到问题，或者有关于，怎么更高效使用agent的问题，我还有一个discord频道 discord服务器，那里有一个很棒的社区，大家互相帮助非常热心，我也经常去那里跟大家讨论，太好了，我会把所有这些链接放在下面，好，谢谢你邀请我来 David [00:50:10]
David Ondrej：彼此彼此彼此