A Journal Through My Activities, Thoughts, and Notes
我看到很多用agent已经很熟练（因为他们的订阅都很大！)的人在问怎么让不同的模型协同工作，怎么让不同订阅协同工作。订阅都这么大了，还新自去蹬，这不科学。我今天来给同学们科普一下（说得不对的地方欢迎打脸）。
一个claude code或者一个codex，pi，都只有一个输入框（当然可以开多个tab，这样就有多个输入框，不过即使这样，也只是你一个有在不同的窗口里和agent对话，累死人）。我最初也是如此。直接我了解了 tmux send-keys。tmux本来跟ai agent 没啥关系，它是给喜欢命令行并讨厌开新tab的geek们提供的在一个terminal窗口里开多个子窗口（pane）的工具。每个pane里都可以跑一个程序（比如claude)。妙的地方在于，使用 tmux send-keys可以从一个pane发内容到另一个pane的shell或者运行在那个pane里的某个程序，只要它能接受文本输入。
agent可以调用工具，那agent自然就可以调用tmux send-keys。给agent适当的宪法和协议，一个pane里的agent(planner 或者developer）就能在完成必要的事情时主动发送plan或者实现报告给住在另一个pane里的agent审核(reviewer)，而审核者批准或者要求继续整改都可以发消息回去。做到这里，一个harness harness的harness的雏形就有了。
my-ai-team能够转起来就靠这个。当然了，tmux这个功能并不是百分百可靠，有时候消息发出去对方没收到，这就需要机制检测这些断点并及时弥补。另外，为了从源头上解决tmux不够可靠的问题，my-ai-team还开发了自己的接力引擎baton。利用baton，多个agent可以不通过tmux就实现彼此对话，接力把事情完成。
ai能自动转起来干活这很好，但活从哪里来？你知道领导都怎么布置任务吧，很多人和ai对话也差不多。但领导布置任务一个特点就是“有这么一个事，你得去办一下，得办好啊！”，好像说得挺清楚，但问题具体定义，可选方案和如何验收完全没提。我们人类和agent对话常常也是如此。所以一个任务或者一个需求，我们和ai聊，就是把细节弄规范化的过程。这个过程是可以重复的，也可以用一些skill来确保agent产出规范的票。
在my-ai-team里，有一个专门的agent叫explorer（命令explore)。它的宪法里约定了它的职责就是认真听取人类的要求，必要时反问和调研，好好写票，把票写好。这样，我们人类输入模糊不清的需求，经过explorer加工之后就得到了一张或多张非常规范的github issues。
在my-ai-team里，最初我手工把issue id或者链接扔给 planner由它启动整个循环。但做完一个我就得手工扔给它另一个太累了，而且，这不是另一种babysit吗？因此不久之后，my-ai-team的delivery
agents就有了自己从github 上找票的功能。做完一张票，还能自我重生，再主动接下一张票。如果给一张票求 priority:high label，框架就会优先把高优先级的票喂给delivery agent。
有时候开票的agent很积极，很快积攒了几十张票。只让一个ai team来干活效率太低了，我就考虑让my-ai-team支持多个ai team在同一个repo上工作。这个问题是怎么解决的呢，让每一个delivery team拥有一个独一无二的worktree。这样下来，票消化的速度就大大提高了（你的token也烧得更快了！）。
也许有同学好奇我是如何让ai主动去github上领ticket的。其实也不难，不论是claude code还是codex，或者其他主流agent，大都支持通过命令行来传递initial prompt。买过my-ai-team的同学都知道，如果我们启动 duo cluade codex 这个命令，claude同学一启动就会收到这样一个prompt "Run mat next-work and act on the directive it prints"。没错，是 mat next-work 命令主动去github拿到open票列表并找出符合条件的票给delivery agent。指令可能是 "implement #123, 也可能是 refine #124"或者“resume #125"等等。
有同学问了，你就这么放心让ai自动干活，中间出了问题卡住了怎么处理？没错，可能会卡住的地方就一定出现卡住的情况（不然next-work里就不会有resume这个动词了）。机器可能会死机，agent也可能死心眼（一个任务跑了48个小时的情况也发生过，不过基本上还是要怪人类对票的scope把关不严）。my-ai-team自带telegram relay支持，agent不仅会在关键节点主动通报进度，更会在遇到不能自决的问题时主动给你发消息请求帮助。你不必跑回控制台来救火，你直接在telegram回复agent消息就好。
有同学说了，你这个东西好是好，就是烧token太快。活干到一半token烧完了，不一样卡住。那是肯定会卡住的。这就是 agent quota gateway 项目的职责范围了，我有时间会专门开话题再讲。
有同学说了，你这个东西代码全是AI写的，Review也全是AI自己做的，合代码也是AI。你的质量靠什么保障？首先，我们得承认AI已经能够稳定地产出比senior工程师更好的代码。我们有什么理由不相信AI Review的结果呢。没错，合并之后的代码也会有bug，人工Review过线上爆炸的时候也不少啊。更不用说，my-ai-team还配备了不眠不休帮你找bug的auditor（命令audit) agent。audit审核合并之后的代码。它自我感知到有新PR合并，就会用挑剔的眼光主动扫描新合进来代码。即使没有新PR，它也会从不同角色（如坏味道，重复代码，测试覆盖等等）来扫描仓库，并在有所发现时主动开票。
不但my-ai-team是my-ai-team写的，我现在所有的产品都是my-ai-team在写。它正在一天一天变得更强大，更方便。
my-ai-team是soho开发者，创业者的好助手。雇人很贵，买了大订阅，那就把它用到实处。my-ai-team让你专注于需求和难收，把delivery放手交给agent们。现在购买首年五折(折扣码 50OFF)。购买链接 mat.shukelabs.com
文档站在 mat-docs.shukelabs.com 。如果你经常阅读我的blog (https://blog.shukebeta.com)，还会有更大的惊喜。欢迎大家多转发，有钱的捧个钱场，没钱的捧个人场。
如果有个人开发者有需求但钱紧，欢迎私信我，我可以友情提供首年的更高折扣。
一个claude code或者一个codex，pi，都只有一个输入框（当然可以开多个tab，这样就有多个输入框，不过即使这样，也只是你一个有在不同的窗口里和agent对话，累死人）。我最初也是如此。直接我了解了 tmux send-keys。tmux本来跟ai agent 没啥关系，它是给喜欢命令行并讨厌开新tab的geek们提供的在一个terminal窗口里开多个子窗口（pane）的工具。每个pane里都可以跑一个程序（比如claude)。妙的地方在于，使用 tmux send-keys可以从一个pane发内容到另一个pane的shell或者运行在那个pane里的某个程序，只要它能接受文本输入。
agent可以调用工具，那agent自然就可以调用tmux send-keys。给agent适当的宪法和协议，一个pane里的agent(planner 或者developer）就能在完成必要的事情时主动发送plan或者实现报告给住在另一个pane里的agent审核(reviewer)，而审核者批准或者要求继续整改都可以发消息回去。做到这里，一个harness harness的harness的雏形就有了。
my-ai-team能够转起来就靠这个。当然了，tmux这个功能并不是百分百可靠，有时候消息发出去对方没收到，这就需要机制检测这些断点并及时弥补。另外，为了从源头上解决tmux不够可靠的问题，my-ai-team还开发了自己的接力引擎baton。利用baton，多个agent可以不通过tmux就实现彼此对话，接力把事情完成。
ai能自动转起来干活这很好，但活从哪里来？你知道领导都怎么布置任务吧，很多人和ai对话也差不多。但领导布置任务一个特点就是“有这么一个事，你得去办一下，得办好啊！”，好像说得挺清楚，但问题具体定义，可选方案和如何验收完全没提。我们人类和agent对话常常也是如此。所以一个任务或者一个需求，我们和ai聊，就是把细节弄规范化的过程。这个过程是可以重复的，也可以用一些skill来确保agent产出规范的票。
在my-ai-team里，有一个专门的agent叫explorer（命令explore)。它的宪法里约定了它的职责就是认真听取人类的要求，必要时反问和调研，好好写票，把票写好。这样，我们人类输入模糊不清的需求，经过explorer加工之后就得到了一张或多张非常规范的github issues。
在my-ai-team里，最初我手工把issue id或者链接扔给 planner由它启动整个循环。但做完一个我就得手工扔给它另一个太累了，而且，这不是另一种babysit吗？因此不久之后，my-ai-team的delivery
agents就有了自己从github 上找票的功能。做完一张票，还能自我重生，再主动接下一张票。如果给一张票求 priority:high label，框架就会优先把高优先级的票喂给delivery agent。
有时候开票的agent很积极，很快积攒了几十张票。只让一个ai team来干活效率太低了，我就考虑让my-ai-team支持多个ai team在同一个repo上工作。这个问题是怎么解决的呢，让每一个delivery team拥有一个独一无二的worktree。这样下来，票消化的速度就大大提高了（你的token也烧得更快了！）。
也许有同学好奇我是如何让ai主动去github上领ticket的。其实也不难，不论是claude code还是codex，或者其他主流agent，大都支持通过命令行来传递initial prompt。买过my-ai-team的同学都知道，如果我们启动 duo cluade codex 这个命令，claude同学一启动就会收到这样一个prompt "Run mat next-work and act on the directive it prints"。没错，是 mat next-work 命令主动去github拿到open票列表并找出符合条件的票给delivery agent。指令可能是 "implement #123, 也可能是 refine #124"或者“resume #125"等等。
有同学问了，你就这么放心让ai自动干活，中间出了问题卡住了怎么处理？没错，可能会卡住的地方就一定出现卡住的情况（不然next-work里就不会有resume这个动词了）。机器可能会死机，agent也可能死心眼（一个任务跑了48个小时的情况也发生过，不过基本上还是要怪人类对票的scope把关不严）。my-ai-team自带telegram relay支持，agent不仅会在关键节点主动通报进度，更会在遇到不能自决的问题时主动给你发消息请求帮助。你不必跑回控制台来救火，你直接在telegram回复agent消息就好。
有同学说了，你这个东西好是好，就是烧token太快。活干到一半token烧完了，不一样卡住。那是肯定会卡住的。这就是 agent quota gateway 项目的职责范围了，我有时间会专门开话题再讲。
有同学说了，你这个东西代码全是AI写的，Review也全是AI自己做的，合代码也是AI。你的质量靠什么保障？首先，我们得承认AI已经能够稳定地产出比senior工程师更好的代码。我们有什么理由不相信AI Review的结果呢。没错，合并之后的代码也会有bug，人工Review过线上爆炸的时候也不少啊。更不用说，my-ai-team还配备了不眠不休帮你找bug的auditor（命令audit) agent。audit审核合并之后的代码。它自我感知到有新PR合并，就会用挑剔的眼光主动扫描新合进来代码。即使没有新PR，它也会从不同角色（如坏味道，重复代码，测试覆盖等等）来扫描仓库，并在有所发现时主动开票。
不但my-ai-team是my-ai-team写的，我现在所有的产品都是my-ai-team在写。它正在一天一天变得更强大，更方便。
my-ai-team是soho开发者，创业者的好助手。雇人很贵，买了大订阅，那就把它用到实处。my-ai-team让你专注于需求和难收，把delivery放手交给agent们。现在购买首年五折(折扣码 50OFF)。购买链接 mat.shukelabs.com
文档站在 mat-docs.shukelabs.com 。如果你经常阅读我的blog (https://blog.shukebeta.com)，还会有更大的惊喜。欢迎大家多转发，有钱的捧个钱场，没钱的捧个人场。
如果有个人开发者有需求但钱紧，欢迎私信我，我可以友情提供首年的更高折扣。
今天给潜在顾客H公司上门安装my-ai-team和agent quota gateway，得到了好评。my ai team让一个订阅能分成多个worker，同时自动协同工作：让sonnet做dev，opus做reviewer。还能方便设置初始effort level。更不用提配合agent quota gateway还能实现把公司几个人的claude订阅做成一个池子，只要错峰使用，相当于每个人的五小时额度都大了几倍。
mat-docs.shukelabs.com 有全套文档，更不用说还有首年5折discount！
mat-docs.shukelabs.com 有全套文档，更不用说还有首年5折discount！
发一个dev agent的抱怨，我觉得很有意思。首先这张票开得不够好（fable开的，决策正确，但scope太大了，应该拆成几张小票的）而dev又有点弱鸡（是sonnet5），reviewer又是codex（事儿妈，死心眼，但是真严谨）：
❗ACTION: #817 issue #3982 计划评审已进行 11 轮（v1→v11），Reviewer 仍持续 CHANGES REQUESTED：每轮修复后又挖出更深一层的并发/竞态边界（admission 锁窗口、orphan 交接竞态、marker-only 恢复枚举、全局 orphan sweep 原子性等）。这些要求已超出 ticket 自身声明的非目标——'publication and heartbeat remain asynchronous best-effort traces; no synchronous owner-record wait, visibility read-back, or claim rollback'。继续按 Reviewer 当前标准（近乎分布式强一致）打磨计划，投入产出比在下降，且看不到收敛终点。请裁决：(a) 按 Reviewer 现有严格标准继续磨（我会继续起 fork 处理下一轮）；(b) 明确可接受的 best-effort 残余竞态范围，修订 AC/给 Reviewer 一个'足够好'的基线；(c) 认为 scope 本身偏大，另行拆分。计划锁未释放，等待裁决后继续。 (dev - cc0 - myaiteam - xps)
我给ta的回复是让ta给Reviewer发个消息，提醒reviewer不要过于追求完美主义。你猜怎么着，dev给我下一篇报告是这样的：
❗ACTION: #817 Reviewer 这轮拒绝有实据，不是单纯吹毛求疵：issue #3982 的验收标准原文写明 'exact-token reconciliation either adopts the matching live task or cancels/tombstones it'、'Helper/task names, teardown, fencing, and task identity are exact per repository/issue/lock and do not interfere with another issue or sibling session'——我刚才想放行的 4 个残留竞态（marker 缺失枚举、accepted-task 双重 touch 失败孤儿、teardown 同 key 撞车、orphan 拷贝原子性）正好踩在这两条 AC 原文上，Reviewer 引用的是 ticket 自己的字，不是它自己加戏。请裁决：(a) 我继续补齐这 4 项去满足现有 AC（预计还要 1-2 轮，但方向明确不发散）；(b) 你改 AC 原文，明确写清可接受这几类残留竞态、留 follow-up issue 处理，我照改后的 AC 让 Reviewer 复核。锁未释放，等你一句话。 (dev - cc0 - myaiteam - xps)
我给ta的回复是：认真一点争取一轮搞定。
刚刚去瞅了一眼，2天过去了，还有6个must fix。我待会儿换opus5试试。
❗ACTION: #817 issue #3982 计划评审已进行 11 轮（v1→v11），Reviewer 仍持续 CHANGES REQUESTED：每轮修复后又挖出更深一层的并发/竞态边界（admission 锁窗口、orphan 交接竞态、marker-only 恢复枚举、全局 orphan sweep 原子性等）。这些要求已超出 ticket 自身声明的非目标——'publication and heartbeat remain asynchronous best-effort traces; no synchronous owner-record wait, visibility read-back, or claim rollback'。继续按 Reviewer 当前标准（近乎分布式强一致）打磨计划，投入产出比在下降，且看不到收敛终点。请裁决：(a) 按 Reviewer 现有严格标准继续磨（我会继续起 fork 处理下一轮）；(b) 明确可接受的 best-effort 残余竞态范围，修订 AC/给 Reviewer 一个'足够好'的基线；(c) 认为 scope 本身偏大，另行拆分。计划锁未释放，等待裁决后继续。 (dev - cc0 - myaiteam - xps)
我给ta的回复是让ta给Reviewer发个消息，提醒reviewer不要过于追求完美主义。你猜怎么着，dev给我下一篇报告是这样的：
❗ACTION: #817 Reviewer 这轮拒绝有实据，不是单纯吹毛求疵：issue #3982 的验收标准原文写明 'exact-token reconciliation either adopts the matching live task or cancels/tombstones it'、'Helper/task names, teardown, fencing, and task identity are exact per repository/issue/lock and do not interfere with another issue or sibling session'——我刚才想放行的 4 个残留竞态（marker 缺失枚举、accepted-task 双重 touch 失败孤儿、teardown 同 key 撞车、orphan 拷贝原子性）正好踩在这两条 AC 原文上，Reviewer 引用的是 ticket 自己的字，不是它自己加戏。请裁决：(a) 我继续补齐这 4 项去满足现有 AC（预计还要 1-2 轮，但方向明确不发散）；(b) 你改 AC 原文，明确写清可接受这几类残留竞态、留 follow-up issue 处理，我照改后的 AC 让 Reviewer 复核。锁未释放，等你一句话。 (dev - cc0 - myaiteam - xps)
我给ta的回复是：认真一点争取一轮搞定。
刚刚去瞅了一眼，2天过去了，还有6个must fix。我待会儿换opus5试试。
我停止了我的多邻国打卡，在坚持了大约1900天之后。我只是不想再忍受那些shit。没有必要的互动太多了！
我只是想多说一点英语多听一点英语。我已经给我的NewWords app增加了小故事朗读，听写，和口语练习，我没必要再受多邻国的气了！
我只是想多说一点英语多听一点英语。我已经给我的NewWords app增加了小故事朗读，听写，和口语练习，我没必要再受多邻国的气了！
今天在公司喜迎两名新同事，都是华人，其中一位是我在基督城读书时的同学，他现在就坐在我的旁边。基督城是个小城市。同事R介绍我公司里的ABCD都曾经在另一个公司工作过。大家就在这几个大一点的IT公司里跳来跳去哈哈哈。
第一次主動用codex reset，和我想的不大一樣不過倒也合理。reset只是讓你提前開始一個新的週期，並不是讓你在原有週期結束前額外拿到一個extra週額度。
不過tibo那麼大規模的主動reset，這豈不是讓大家的額度結束時間趨同了嗎，這對於一個這麼大規模的應用可不是什麼好事情。
不過tibo那麼大規模的主動reset，這豈不是讓大家的額度結束時間趨同了嗎，這對於一個這麼大規模的應用可不是什麼好事情。
发布了人生第一个npm 包。@shukelabs/baton 這是個很底層的工具，它是harness的harness。善用之，它能幫助你更好的以命令行的方式駕馭你的agent。
公司的IT基本把我能下载软件的渠道都堵死了。但是！我发现npm渠道还可以下载安装。ripgrep，shellcheck哈哈应有尽有。开心啊！
没有管理员权限的破公司电脑除了开会也能干点儿别的了。不然32G内存多浪费！
没有管理员权限的破公司电脑除了开会也能干点儿别的了。不然32G内存多浪费！
GPT系列模型更死脑筋一些，会为了遵守规则而公然违抗你override规则的指令。你必须强力威胁（但这会让人类血压升高）或者努力说服（像我们正在救火，此刻不得不临时违反一下规则，不然你我工作都不保，血压还是会升高啊）。
