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规则的指令。你必须强力威胁（但这会让人类血压升高）或者努力说服（像我们正在救火，此刻不得不临时违反一下规则，不然你我工作都不保，血压还是会升高啊）。
#english
I wish she were moving back though.
可以理解成：
“不过，我倒真希望她能搬回来。”
或者更自然一点：“但我还是希望她能搬回来住。”
关键是两个地方：
- I wish + 过去式/过去进行时：表示对现在或未来不太可能/与现实不符的事情的一种愿望。
- though 放句尾，表示“不过 / 但是 / 倒是”，通常是在前面的内容基础上补一个转折。
比如：
She’s doing really well in Australia. I wish she were moving back though.
她在澳大利亚过得挺好的。不过我倒是希望她能搬回来。
这里的 were 是虚拟语气。口语里你有时也会听到 I wish she was moving back，意思基本一样；were 更符合传统语法。
另外，move back 不只是“回来”，而是搬回原来住的地方。所以这句话通常带有一种“可惜她不回来”的感觉。
I wish she were moving back though.
可以理解成：
“不过，我倒真希望她能搬回来。”
或者更自然一点：“但我还是希望她能搬回来住。”
关键是两个地方：
- I wish + 过去式/过去进行时：表示对现在或未来不太可能/与现实不符的事情的一种愿望。
- though 放句尾，表示“不过 / 但是 / 倒是”，通常是在前面的内容基础上补一个转折。
比如：
She’s doing really well in Australia. I wish she were moving back though.
她在澳大利亚过得挺好的。不过我倒是希望她能搬回来。
这里的 were 是虚拟语气。口语里你有时也会听到 I wish she was moving back，意思基本一样；were 更符合传统语法。
另外，move back 不只是“回来”，而是搬回原来住的地方。所以这句话通常带有一种“可惜她不回来”的感觉。
#网友语录 Jason Fried
You don't need to make room for Liking More Things. It's not LIFO or FIFO, it's just MORE IN.
You don't need to make room for Liking More Things. It's not LIFO or FIFO, it's just MORE IN.
