2026-01-24

今天一觉爽睡到了 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