从终端习惯到 AI 协作范式的跃迁

Kun Chen 是一位拥有二十年终端开发经验的顶尖工程师，曾任职于 Meta、微软和 Atlassian。他坚持使用无边框终端环境（如 West Term 和 Herder），并强调双手不离键盘是保持心流状态的关键。他指出，尽管终端学习曲线陡峭，但一旦适应，就能让思维成为唯一流动的媒介——键盘操作的流畅性极大提升了专注力与效率。他对 Herder 的推崇，源于其对 Agent 工作流的原生支持：不同于传统终端复用器（如 Tmux 或 Zellij），Herder 能识别并追踪后台 Agent 的运行状态，使用户无需在多个标签页间切换记忆任务内容。这一特性直接催生了他对下一代协作框架的构想：当 Agent 能力足够强时，人类不应再手动管理多任务上下文，而应由一个主 Agent 统筹全局。

我开发 FirstMate 是因为我觉得 Agent 能力越来越强之后，应该能替我去处理这些事儿。

有时候我看到有人开二十二十三十个绘画，但后来我简直要疯了，因为是啊，二十个绘画你得全记在脑子里。

FirstMate：作为‘首席协调员’的主 Agent 架构

Kun 的核心工作流围绕 FirstMate 展开——一个由他自研的主 Agent，负责协调约二十至三十个开源项目中的 Issue 和 PR 处理、代码审查、状态查询等事务。他强调，FirstMate 并非执行所有任务的‘万能工’，而是智能的任务分发者：当用户提出请求（如‘苹果审核通过我们这个 APP 了吗？’），它不会亲自执行，而是委派给特定的 Crew Mate（子 Agent），从而避免自身被阻塞，确保用户可随时继续交互。这种设计使他始终处于‘大脑清空’模式——想法即指令，执行全外包。

信任的建立是渐进过程。早期 FirstMate 常出现任务错配或重复执行等问题，Kun 通过持续反馈与规则迭代逐步优化其调度逻辑。如今，系统已能稳定运行，仅在极少数情况下他才会手动跳入子 Agent 绘画（通过 Herder 的视图切换功能）进行深度介入——类比真实团队中‘绕过主管直接沟通下属’的高效场景。

我就不断优化这个过程，最后终于调到了一个很舒服的状态，可以直接让 First Mate 帮我处理所有这些事，而且再也看不到什么错误或者不合理的任务分配了。

语音优先、模型分层与规则驱动的工程哲学

Kun 几乎全程采用语音输入提示词，仅在涉及路径、URL 等结构化数据时辅以键盘输入。他选择 Sonnet 3.5 v2 作为主 Agent（FirstMate）的核心模型，因其是首个能完整闭环执行复杂任务（如设计审查、代码生成、状态查询）的转折点。他指出，FirstMate 需要强大的上下文推理能力——例如在提及‘Herder 工作区设计’时，必须精准关联历史对话与未完成方案。

其系统另一关键在于规则驱动的分层调度机制：Kun 在专用配置文件中定义了子 Agent 的使用场景、模型选择与推理强度参数。当 FirstMate 分配任务时，会依据这些规则匹配最合适的执行者，而非统一调用最强模型，从而在成本与效率间取得平衡。这种‘能力-成本-可靠性’的显式权衡，构成了其 AI 编程工作流的工程化基石。

五点六在 X I 上就是我的 first mate……它需要处理大量的上下文，它得理清很多不同的事情。

Herder 与 First Mate：复杂上下文下的智能协调

在 Kun Chen 的工作流中，First Mate 是一个高度依赖推理能力的 Agent Herder，其核心职责是理清多线程任务中的上下文依赖关系——例如，当用户提到“Herder 工作区试图设计”时，First Mate 必须准确识别这是指“前阵子做过”的某个具体项目。这种能力使它能高效组织多个子 Agent（即 Crewmates），并根据预设规则分配任务。这些规则存储在用户自定义的配置文件中，明确规定了在何种场景下应启用哪个 Agent、调用哪个模型、以及设定多高的推理强度。

值得注意的是，Kun 对不同模型有明确的偏好策略：对于高复杂度的技术与产品设计，他坚持使用 Fable，因其具备他所看重的深度与创造力；而默认模型虽为 GPT-5.6，但仅出于订阅方案的实用性考量。他甚至维护一个配额追踪系统，实时监控各模型的 token 消耗，以便在配额耗尽前合理分配资源。这种精细化管理源于一个现实困境：当前主流大模型订阅套餐（如 200 美元档）根本无法支撑高强度 Agent 工作流的需求。

我觉得我会建议大模型公司认真考虑推出更高等级的套餐。对。五百，因为现在两百美元这一档根本不够用。

我想要的反而是反过来，我想要更慢但更便宜的模式。因为有太多任务是那种后台任务，我根本不关心它是不是很快完成，对吧？我关心的是我总共能干完多少活，因为现在我的总额度才是瓶颈。

结构化交互与决策闭环：从白板到待办事项

为应对多项目并行带来的上下文过载，Kun 引入了基于 Levish 的可视化工作流，将原本散落在终端中的文本流转化为直观的树状结构（如 Native now report tree 和 work tree）。这种层级化组织不仅提升了任务可读性，还支持深度交互——例如，他可直接在生态白板上拖拽架构图框、实时反馈调整，并将修改指令回传给 Agent。这种“所见即所得”的协作方式极大降低了认知负荷，使他能专注于真正模糊的决策点。

在决策流程上，Agent 最终会输出多个可行方案，并明确标出需用户拍板的开放性问题。Kun 的策略是：将所有想法一次性输入 First Mate，之后仅处理那些 Agent 无法自主判断的关键决策。为此，他精心设计了触发机制，规定 First Mate 在何种条件下必须暂停并请求人工介入，以避免 Agent “放飞自我”导致返工。这种“想法输入—自动执行—关键决策”的闭环，是他在高并发任务中维持深度工作状态的核心机制。

这是我做的一件事，就是把我所有的想法都告诉 First Mate。另一件事就是处理那些我必须做但 First Mate 自己决定不了的决策。

模型选型与成本博弈：从 Luna 到开源的现实权衡

在模型选择上，Kun 展现出极强的实用主义倾向。他指出，GPT-5.6 在 Extra High 或 Ultra 模式下存在严重的 token 消耗异常——初期因上下文窗口阈值误设（372K vs 实际 272K），导致超限请求被重复计费；而 Ultra 模式更因过度启用子 Agent（尤其是全 Ultra 级子代理）而加剧消耗。相比之下，X High 模式反而是性价比最优解：虽名为“X High”，但速度与成本平衡极佳。

基准测试 DeepSweep 的结果进一步佐证了这一观察：Sonnet-5 在 Low→F High 区间表现稳定，但一旦启用 Max 推理，其成本与性能曲线严重失衡——模型本身智能不足却强行“过度思考”，反而造成大量 token 浪费。Luna 也存在类似问题：其智能跨度极大，但低智能端易陷入无效工具调用循环。因此，Kun 将 Luna 仅用于对延迟极度敏感的场景（如家庭自动化），而日常开发任务则回归 SoA（Sonnet-5）。

至于开源模型，尽管本地部署（如 Kimi-2.7 Code）或 OpenRouter 上的中价方案成本更低，但 Mac Mini 作为其“个人算力中心”已承载大量开发任务，资源竞争使其难以腾出算力给开源 Agent；而云部署的节省又不足以覆盖迁移成本。最终，他仍选择以 Luna 为主力，辅以 Grok（利用其免费 X API 权限）与 Claude（通过 Cloud Code 精简生态）的混合策略。

Grok 4.5 非常好用……它就像是开了快速模式的 Opus。我去，对它基本上能干 Opus 能干的任何事儿，而且速度超快。

Grok 与 Agent Harness 的演进：速度、集成与定制化

Grok 4.5 给人的直观感受是 “开了快速模式的 Opus”——它几乎能完成 Opus 能做的所有任务，且执行速度大幅提升。更值得注意的是，在 Grok Build Harness（即 Grok Harness）中，用户能免费获得 X API 的访问权限，从而可以读取推文、搜索内容——而这些功能在常规情况下是需要付费的。这一集成显著降低了信息获取的门槛，使 Grok 成为我日常梳理新闻、检索推文的主力工具。它也是目前进步最快的 Agent Harness 之一，尤其在后台轮询、任务调度等底层机制上，已超越早期的 Codex。与此同时，我也持续使用 Open Code，欣赏其流畅的 TUI 体验；但随着实践深入，我越来越倾向使用 PI（Perplexity Agent），因其支持深度定制：几乎可以重构 PI 的每一个行为模块。这种可定制性，正成为我评估 Agent 工具链的核心标准。

Grok 4.5 的看法是，它就像是开了快速模式的 Opus。我去，对它基本上能干 Opus 能干的任何事儿，而且速度超快。

我之前给你看了一个东西，就是我菜单栏上的那个配额小部件，还记得吗？……这是我自己做的。而且它可以自我修改。你现在能看到它上面有一堆东西，这些功能绝不可能同时出现在一个产品里。

软件的未来：自适应、自我修复与个体化 Agent

我坚信，未来软件将呈现光谱化分野：一部分用户偏好开箱即用的标准化工具，依赖社区验证的“最佳实践”；另一部分则追求高度可定制、可进化的个人工作流。我的 Baby Menu 就是后者的具象化——它从一个空壳开始，通过与 Agent 的持续对话自我迭代，最终整合了 GitHub 统计、CPU/内存监控、Cloud 与 Codex 配额等异构信息。没人会为大众生产这种高度个人化的组合体，但它却是我效率的关键支点。

更进一步，这种“可对话、可修改”的范式正催生自我修复型软件系统。以 First Mate 为例：它不仅读取 .md 指令文件与 bash 脚本，还能在出错时自动绕过 bug，继续推进任务——即使脚本存在缺陷，也仅降低效率，而非中断流程。这与传统软件形成鲜明对比：传统 bug 常导致崩溃，而智能 Agent 的 bug 往往只是性能衰减。挑战由此转移：人类不再需修补每一个细节，而是聚焦于真正关键的决策环节。

它会自己绕过这个 bug。所以现在这个软件几乎是不可阻挡的，你没办法阻止 first mate 去做它需要做的事。

No Mistakes：自动化对抗性审查与质量保障闭环

面对 AI 生成的复杂代码（如 Fable 或 GPT-5.6 的输出），手动审查已不可持续——时间成本过高，且易因疲劳漏检。为此，我构建了 No Mistakes：一个自动化质量保障 Agent。其流程高度结构化：首先解析原始 agent 会话以还原开发意图；随后在最新主干上变基，避免合并冲突；接着启动对抗性审查（主要使用 GPT-5.6 Medium 模型），自动修复显性 bug，将隐性问题升级至人工审批；再执行测试、文档校验，并推动 PR 合并，全程监控 CI 流程直至绿色通过。

该系统已在我三个月内处理了 1,000+ 次改动，覆盖 59 个仓库，其中 63% 的改动被成功拦截并修复。数据显示，对抗性审查环节贡献了最大比例的问题发现与修复——尤其 GPT 模型在识别边缘场景方面表现卓越；其次为文档一致性检查，常揪出 README 与代码逻辑脱节的隐患。这印证了：高质量交付无法绕过系统性验证成本，正如团队开发中人工 Code Review 般不可或缺。

我的操作就是输入 N M，这是 No Mistakes 的缩写，加一个 Y，意思就是把当前工作目录里所有的代码改动放到一个分支上，交给 No Mistakes 处理。

多亏了 Agentic Engineering，你可以开始追踪你工作的几乎一切……如果是人类追踪起来就难多了。

从工具焦虑到价值聚焦：Agent 配置的理性实践

许多人在搭建 Agent 工作流时陷入“工具迷宫”：过度优化配置却迟迟不产出产品。我自己也曾陷入这一陷阱——数周沉浸于修工具 bug，反使核心开发停滞。转折点是引入 First Mate：它接管了琐碎任务（如 bug 修复、流程自动化），使我得以自然转向模糊但高价值的决策，比如产品设计与用户需求洞察。如今，我的时间分配更趋健康：约 10–20% 用于系统维护，80%+ 用于真实产品构建（如面向儿童的 AI 家教 Habit 和 iOS App）。

这种转变源于对“第一性原理”的回归：所有工具皆从真实工作阻力中生长而来，而非为炫技而堆叠 Agent。单干后，我摆脱了大公司中“协调瓶颈”，但面临新挑战——如何高效与 AI 协作？答案正是这些自建 Agent：它们不是目的，而是消除摩擦的杠杆，最终服务于可衡量、可持续的产出节奏。

这是我开始用 First Mate 之后一个无心插柳但自然出现的结果。

单干的自由与瓶颈转化

在大公司工作时，即使做到较高职位，Kun Chen 也发现自己大部分时间都花在协调与沟通上，而非亲手开发。这种组织层级带来的摩擦成为他效率的核心瓶颈。而转向单干后，唯一的瓶颈变成了他自己的工作产出能力——这反而激发了他用 AI Agent 自动化任务的动力。在实践中，他不断遇到新问题：如何验证 AI 生成的代码？如何与 AI 进行更互动的规划（而非面对终端里冗长文本）？如何并行处理二三十个绘画任务而不崩溃？这些问题倒逼他开发了一系列工具，最终意外成为多个开源项目的维护者。

单干的时候，除了你自己，没有别的瓶颈。所有事情的瓶颈都在我自己身上，在我自己的工作产出上。

我开始碰到这些问题，然后就被迫去开发这些工具，因为没有别的办法能很好的解决它们。

Agent 原生接口：软件重建的底层逻辑

Kun 认为，当前大量 SaaS 软件本质上是“人用界面 + 数据库 + 扩展系统”的组合，而未来这类界面将大幅萎缩甚至消失。真正有生命力的软件将转向无头架构（headless），并为 Agent 提供高效协作接口。他以 GitHub 为例指出：其 MCP 服务器在基准测试中表现远逊于 GitHub CLI——更慢、更多轮交互、更高 token 消耗。原因在于 CLI 已被长期优化，并大量存在于大模型训练语料中；而多数 MCP 服务器仍停留在“人类 CLI 的封装”阶段，并未为 Agent 重构交互逻辑。

他进一步提炼出十条 Agent 友好型 CLI 设计原则，并开源于 x.md。例如：使用 token 效率高的输出格式（避免冗余 JSON 结构）、精简默认 schema（只返回必要字段）。基于这些原则，他开发的 GitHub XE、Chrome DevTools XE 等封装工具，在功能不变前提下，平均成本降低超 20%、延迟显著改善，验证了接口设计对 Agent 性能的关键影响。

GitHub 的 MCP 服务器可能是市面上效率最低也最没必要的 MCP 服务器……它总是比 CLI 更贵。

遵循这些原则，我就能持续做出封装和工具，让他们比原来的版本对 agent 更高效。

技术采纳曲线：从捣鼓者到主流

Kun 指出，AI Agent 将接管 99.9% 的软件操作，人类只需与主 Agent 对话即可完成任务。但这一转变不会一夜发生——它遵循历次技术革命的标准采纳曲线：初期由一小群纯粹出于兴趣的“捣鼓者”推动，他们探索工具、暴露问题、提炼方法；随后通过开源分享、视频演示、社区共建，逐步形成可复用的实践范式；最终才被更广泛用户接受。他强调，那些因短期效果不明显而放弃 AI 的人，往往忽略了从零构建的新项目相比遗留系统能获得的指数级提升。

他建议听众关注其 GitHub 仓库（所有工具开源）、YouTube 频道（完整编程演示）及 Discord 社区（实时答疑），这些是进入 Agent 原生工作流的高效入口。他坚信，理解技术扩散的节奏，比期待“全民顿悟”更现实，也更可持续。

我觉得这其实是一个学习曲线的问题……那些领域的人试了 AI 之后，会觉得哦，好像也没那么有用，我干嘛要花功夫去认真用呢？