2026-01-25

今天去理了个发，回来发现系统不稳定了，结果最后是鸡哥的起了两个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. 上线之后重新迁移一下集群