2026 工作日志

过去的几天过的比较紧凑，因此没有记录。但是停止记录是不行的，因此我现在捡起来然后一并记录。

除了事多以外，为什么没记录呢？

1. 因为心中恐惧要记录就得坐下来专门花 30min 以上来记录一天，这其实是因为对于记录日常有了一些恐惧和负担，是不可取的。
2. 通常我只愿意在一天真的结束之后开始记录这一天，但是仔细想想这其实有一些反人类，因为我现在睡觉基本都是到了该睡觉的点迅速钻进被窝，而不是因为想要做的事情真的全部做完了（真的会有这种时候吗？）。这就导致其实有空的时候不要记录，而真的该记录的时候又必须迅速进被窝了，再加上 1 的问题。

两者一结合就越积越多。

1. 今天做了什么：

   更正一下，是最近几天做了什么

   1. 在 sc 的安利之下开始使用 neovim 了。为什么使用？我看到 nvim-orgmode 似乎已经真的成为了一个可用的 org-mode 了，同时我对 emacs 开始感到厌烦了：

      • 无穷无尽的更新失败
      • 令人费解的调试和报错
      • 对我来说徒增负担但是毫无用处的灵活性
      • 我不懂 emacs-lisp 也不想懂

      多年来我为了使用 orgmode 一直在忍受上述这些，但是没有任何一个其他地方可以让我好好用 org-mode，现在 nvim 阵营似乎有了可替代方案，为什么不试试呢？

      因为我本就是多年的 vim 用户，在 emacs 里也是用了 evil-mode（vim-mode），因此我从来不觉得使用 vim 能给我带来多大的负担，在 vscode 里和 idea 中没有 vim 我就无法生存，所以直接使用 nvim 对我来说一点问题都没有。

      既然阻碍没有了，那么考察一下 nvim 的生态，我品了品，nvim 因为没有vimscript 的历史包袱，直接使用了 lua 作为其配置语言和插件语言。所以可以轻装上阵，而且社区也非常活跃。我看现在 neovim 的插件系统也被一个叫做 lazy.vim 的系统一统天下。nvim 对于其插件和配置系统的设计应该是有组织有计划地专门针对 vim 原有的痛点进行了大胆革新。vim & emacs 里面大约存在无数个想要一统江湖的类似尝试但是因为社区太分散，应该是没有一个真正成功的。

      于是我直接尝试了一下 lazyVim，好家伙，这下我感到我直接拥有了一个vscode，而且这个 vscode 可以在终端里运行，你知道这有多爽吗？

      现在我有了基于全新基建的强大旧日支配者，以及它配置起来非常之巨简单，灵活性和便捷性被收敛的恰到好处，我的旧痛点基本全部被解决了。

      我几乎没费什么时间就已经把相当多的工作流切换到这个上面了，我现在使用tmux 开 5 个 window 然后每个 window 在一个 folder 之下开 nvim，nvim中左边是目录树，中间是代码，右边是 opencode 和 terminal。

   2. 更新了一版本 legion，我大幅降低了 legionmind skill 的文本量（4k 行减少）目前用下来感觉需要我操心的地方变得更少了，但也不知道是因为我最近都在用比较聪明的模型还是因为这个版本的 legionmind 真的变聪明了。

   3. 搭建了一个 openclaw，minimax 2.1 还是有点傻，但是作为一个个人助手我觉得 openclaw 相当行了，因为他基本等于一个有记忆的 chatgpt + 手和脚（可以操作我的电脑）

   4. 给 Yuan 新增了 http-proxy 的功能，添加了 metrics 啥的。

2. 有什么想法

   我有时候感觉用 AI 写东西有点像去调试一段不是特别懂原理的代码，通过不断地测试其行为或者打印 log 来辅助调试，这里改一点那里加一点，直到最后拿到一个满意的结果为止。探究一下这种感觉的由来：

   使用 AI 写代码，究其过程，是人类输入一段 prompt，包含了一些具体的指令，然后寄希望于 AI 能够弄明白这段指令背后的隐含指令和信息，然后正确地完成工作。

   可以将希望传达给 AI 的指令分层：最上层是本次任务的指令。其下是这个软件项目的一些做过的技术决策，权衡利弊之后总结出来的适用于这个项目局部的最佳实践。再下一层是项目所要解决的问题的问题领域的背景信息。再下一层是使用 AI的软件工程自己的专业背景知识，他的个人喜好、技术偏好、风格偏好、历史经验、思维方式的积淀。最下面一层是这个世界的背景知识。

   在一次与 AI 的对话中能够让 AI 清晰明了的，其实只有本次任务的指令，然后寄希望于 AI 拥有足够的有关世界的背景知识和解决问题所需要的背景信息。

   因此可以推理出，如果一个任务的上下文足够小，给出的指令清晰无比，且没有什么历史包袱，AI 应该是很容易能够高质量的完成任务的。如果有大量隐含的背景信息，那么就容易搞出一些莫名其妙的活。

   Legionmind 要做的就是让 AI 自己积累有关与本项目和问题领域本身的背景知识和最佳实践。这要求 AI 要么具备良好的逻辑思维能力和记忆力（context 容量），要么 AI 本身具备充沛的世界背景知识，超过这两者的，没法救他。

   —

   然后就是我觉得 nvim 真是相见恨晚。

3. 明天打算做什么

   明天去 sc 家参观他的新家，然后一起打桌游，顺带给 sy 看看雪具。

zl 来了，信息量很大，我得消化一下。玩了桌游，惨剧循环，我们在理解规则上花了三个小时，终于在最后一个剧本我扮演反派剧作家的时候让我感受到了这个游戏的甜蜜点，最终以我的彻底胜利终结了游戏。

今天是克制的一天，我发现自己在 25 岁之后面对情绪有了一个明显的长进，那就是在情绪之外明显伴随着一丝理智在 copilot，这一丝理智在情绪的巨大反应堆中设置了一条镉棒。没有这条镉棒情绪会失控，引发自激的链式反应，可能带来无数无法挽回的后果；在这条镉棒的作用下，我开始明了什么话可以说，什么话不能说，什么事情可以做，什么事情不能做，什么决定可以做，什么决定不能做。这是一种发生在我身上的可喜的变化。

1. 今天做了什么：

   1. 今天使用 legion 做了 yuan 的 http proxy 的设计和实现，我觉得用起来还是相当丝滑的，途中我去审查了一下它的设计，针对其中一个点（如何选择一个可用的 terminal）进行了修改之后放手交给 agent 放手一搏，效果相当不错。
   2. 我还用 legion 做了一个 midas 自动更新的事情，不过 AI 一直做的很差，没能正确理解我的需求，没能正确理解 @yuants/protocol 的用法，我有几个怀疑的方向：AI 的智力不够（deepseek 可能还是显得不太聪明了）；review 的不够严格；或者就是文档知识库不够严格
   3. 你妈的晚上被告警弄起来了，host 莫名其妙挂了，看起来是有一个 cpu 使用的峰值导致 host 进入一个无法自己恢复的状态。host 的 log 是一坨，我的评价是：告警有用，日志依托答辩。记一笔！

2. 有什么想法：

   1. 洗澡的时候想了一下目前我和 AI 的协作的最关键点。一个是 ai agent 自身的服务可用性，不要跑着跑着退出了啥的，另外提一嘴 ralph loop 基本也就是通过粗暴地不断重试来提高可用性；另一个点呢就是我如何接受 AI 给我的输出，比如下属对上级的汇报尚且需要一个 PPT 或者干脆一个专业的中层领导来做这个“昂贵的传声筒”，AI 对人类的汇报怎么能只局限于平铺的 Markdown和代码呢？AI 的 report 能不能每一条都 link 一个 artifact？能不能有一个 Citation Agent 专门负责这个部分？

      不过我目前对于 AI 的用法比较局限，只集中在编码任务上了。

   2. 仔细思考一下有关于为什么我已经有了一套 multi-agent 系统之后，这个系统稳稳地朝着阴沟里翻车的方向开去了，前面的推测中大致提到有三种可能性，分别是：

      1. AI 自身的智力水平
      2. 人类的 review 不够严格
      3. 知识库不够翔实，不足以提供更正确的信息来供 AI 来快速启动

      我们来仔细思考一下这几个点，其中 1 根本不用思考。在方向 2 上努力确实会可以依靠一篇越来越翔实的 RFC 文档，来给后续的步骤以足够正确的方向。但是这样的开发方式就好像我们回到了瀑布流 开发模式，通过一个线性流程来完成工作：

      需求分析 -> 后端设计 -> 后端开发 -> 前端开发 -> 联调测试
      

      形成的因素也有两个层面：技术层面和 组织与流程的层面，但是组织流程的的层面是 *主要因素*。

      技术层面是任务之间天然存在依赖关系，比如前段必须等待后端提供接口才能开始开发、后端又必须等待产品的 CRD 写好之后才能开工。

      作为人类组织，瀑布流开发模式存在：效率低下、质量风险难以暴露、灵活性差、团队矛盾等问题。而作为我与 AI 的协作方式，效率和团队矛盾天然不存在于 AI 的世界中。好比我和 AI 是生活在两种时间维度的实体，我的一天对于 AI 来说就好像是一年一样。哦效率低可能会多费一些 token，不过这不是我目前最关注的问题。我实际上面临的问题是需求、或者事实的理解错误带来的质量风险，灵活性也差。

      我必须想到一种方式能最大程度利用 AI 的能力的前提下最大限度地解放我自己。按照人类之间互相组织的经验，我必须成为指挥树上层级更高的节点，能够放心把事情交给 AI 的同时，让它不偏离赛道。

      最关键的两点：

      1. 意图对齐
      2. 分层验证

      这点还要再深入思考一些。我感觉我得多用用，品一品；

   3. 我需要警惕自己这种拿着锤子找钉子的状态的坏的一面：路径依赖、输出大于理解

3. 明天打算做什么？

   明天 zl 来了，计划锻炼一下、吃个饭、玩玩桌游

今天去理了个发，回来发现系统不稳定了，结果最后是鸡哥的起了两个terminal_id 同样的服务，互相抢占导致出现大问题。

1. 今天做了什么：

   1. 尝试把集群迁移到 NAT 后面，当然是使用了全新的 legion 来完成这个事情。 我的操作是这样的：

      • 先修改 kops 集群，创建新的 vpc，使用了 172.21.0.0/24 和 172.21.1.0/24 网段。然后创建了一个 NAT 用于流量出口。

        原本打算采用 10.0 开头的网段，但是尝试之后发现 aws 不让创建这种cidr，于是就改成了 172.21 开头的网段，这里面有个坑，就是需要在cluster 资源中把原有的 loadbalancer 指向对应的 vpc（原本是隐含的默认指定，现在多了一个 cidr 就得手动指定一下）

      • 然后是创建新的 instance group，指向新的 vpc，中间碰到一个小插曲，就是新的 ig 没有 s3 权限，不知道怎么回事，手动添加之后节点正常加入集群。

      • 下一步是手动迁移服务到新的 ig 里

      • 最后下掉原有的 ig

      结果搞定之后发现集群出口流量只有一个 ip 了，让我们的 ip 限流的服务弄的有点崩溃，无奈只能回滚，必须先把 http proxy 的技能点点了才能进行下一步了。

   2. multi-agent 被用于实践一个自动更新 midas 净值的脚本，deepseek 吭哧吭哧写了好久，我倒是感觉挺满意的。这里面就是有一个比较核心的问题就是如果设计早期有一个错误我没发现，那么等着我的就是巨量的 token 和时间浪费，因为我发现 agent 干活也不算快。

      目前这些 coding agent 还是挺原始的，经常会用着用着因为网络等问题退出崩溃，想让它们来完成一些严肃的 long running 的工作还是有点 SLI 还是有点差，这可能也是一个机会，简单一想这是需要一些软件工程高可用等方面的知识来 work 的。

2. 有什么想法：

   今天想法比较少，都内联地写进上面的章节了。

3. 明天打算做什么？

   1. Yuan 的 http proxy 机制设计一下。
   2. 上线之后重新迁移一下集群

今天一觉爽睡到了 11 点，感觉一身轻松，好久没如此放肆地睡过觉了。

1. 今天做了什么：

   1. 上线了 node-unit 的新版本，比较敢放心上它的原因是我有比较详尽的端到端测试，具体来说就是 docker 启动了一个 timescaledb（postgresql17），然后启动了两个 node-unit，并在数据库里插入了 21 个 @yuants/portal 来测试，最终收敛成一人一半的状态。

      这个测试基本可以测出来当一堆无主的 deployment 出现的时候，上线了两个node-unit，就可以观察到轮流抢占 deployment，要说真差点啥，一个是真正占据 cpu / memory 的工作负载，另一个是需要有 node-unit 因故下线这个场景。

   2. 使用新的 multi-agent 版本的 legionmind 在 Yuan 中攻克了 vendor-gate earn 账户输出账户流的问题。我让 agent 先使用 legion 进行文档的创作，总计输出了下面这么多文档：

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      感觉是个像样的工作流了。不过我的新的 multi-agent 系统和原有的legionmind 的文档写作有一些冲突，我应该仔细考虑各个事情的边界，比如每种文档该怎么写的规范应该放到一些单独的 skill 里，然后 legionmind 应该是一个工作流程的说明。每种 agent 都应该能加载几个比较小的 skill 来辅助它们完成自己的工作。

      还有一些不足的问题是，它第一次工作的时候翻了一个错误，把账户流输出到=account-actions-with-credential.ts= 中去了，这是因为我要求它参考vendor-okx 来完成 earn 账户的接入，我之所以这么要求是因为目前只有 okx的 earn 账户也被接入成一个 account 了。但是 ai 把这其中一些过时的实践也学去了，目前的 exchange 接入标准是把账户全部通过=provideExchangeServices= 发布，而不是使用=provideAccountActionsWithCredential= 来接入账户。

      这些知识是一个全新的 AI Agent 所不具备的，这些知识该怎么建模呢？我该怎么为 AI Agent 提供这样的项目上下文作为它的外置大脑呢？这是一个值得深思的问题，明天需要仔细思考。

   3. 下午做饭来招待 sy 的朋友们，给我累坏啦，那么明天还是继续工作吧~

2. 有什么想法：

   • 如同上文所说，我需要仔细考虑如何紧凑地为 AI Agent 设计一个外置大脑，最简单的可以从一组 AGENT.md 开始，我之前有尝试过，但是维护这些文档本身的overhead 其实也挺高的，区分垃圾和真正值得记录的经验是一个很难的问题。目前看来记忆和其他的 prompt 一样，只不过可能多了一个 agent 自己有一条环路去更新记忆，最重要的还是如何去衡量 AI Agent 工作的结果。

   • 有关于上一点，我看到一篇文章我感觉很有意思，现在让我用我的语言来摘要它： 首先，对于 agent 一步工作的评估，这个评估可以分成几类：

     1. 静态工具 eval：编译器、linter、单元测试、e2e 测试
     2. 模型 eval：用另一个 LLM 按照我们定义的 prompt 来判断
     3. 人工 eval： 我来判断

     然后对于一个 Agent 的系统性评估分两种：

     1. 能力型：回答这个 agent 能做什么？而且可能通过率很低比如我要用 legion 来逐步执行更大、更难的任务，感觉像是探索一个新的边界。
     2. 回归型：它还能保持以前会的能力吗？比如重复地测试一些任务，保证还能够稳定实现。

     那么当一个新的能力被引入之后就应该从能力型过渡到回归型。

     这篇文章还提到两个很重要的指标，分别是 pass@K 和 pass^K

     • pass@k：k 次尝试里至少成功一次尝试越多，至少成功一次的概率越高。 适用： 你只在乎“至少找到一个可用解”的场景

     • pass^k：k 次尝试必须全部成功尝试越多，要维持一致性就越难。 适用： 用户期望每次都可靠的生产 agent

     FYI: 参考这篇文章

   • 精力还是有点差，下午 work 了一会，晚上做了个饭就感觉有些累，我什么时候能像 CZ 一样不用睡觉呢？

3. 明天打算做什么？

   1. 思考下这个 eval agent 的模型，继续迭代这个 multi-agent 系统。
   2. 集群安全问题，必须搞了
   3. legion-github-bridge

今天有点感冒了，有点头痛，产能低下，不过我很高兴我开始做每日总结了。

1. 今天做了什么：

   1. 在 AI 的帮助下设计了一套 multi-agent 系统，这个系统还没经过系统的打磨。
   2. legionmind-github-bridge 又往前走了一步。
   3. 修改了一下 node-unit 的抢占设计和实现，之前在某个 node-unit 在 failed 的时候。其下所有的 deployment 都会被清除，现在只会一个一个清理。
   4. 去考了一下期货券商开户中金所的考试，竟然要全程打开摄像头不许最小化不许切屏幕，好在可以无限尝试，这可难不倒我，95 分高调通过。

2. 有什么想法：

   我的目标是在尽量少的磨损的情况下做到 agent 自治，目前我的工作流是这样的：

   1. legionmind 作为一个开发工作的 SOP，它是一个 agent skill，我喜欢 agent skill
   2. opencode 作为 agent 的实体，我使用了其中的 bash / tool calling / langraph / command / subagent 等能力，如果我有一天要抛弃 opencode，那么这些就是我的待实现清单。
   3. 现在我有点头痛的就是如何组合 skill 和这些子代理

   头痛一天，到晚上才有点头脑清明，我发现一天结束的时候写这些想法可能不是一个好办法，也许应该只记录事实，然后等到明天早上醒来的时候再总结想法。

3. 明天打算做什么？

   1. 利用这个 multi-agent 系统干点啥，把 gate 的理财账户接一下好了
   2. 继续 legionmind-github-bridge
   3. 集群安全性，如果有时间的话
   4. 重新开始进行 work 计时。（重要）
   5. 明天 sy 的朋友们会来做客，因此可能工作时间要被抢占