这是我在 Polymarket 上交易两年以来体验最差的一周，宕机了五六次以上，每次都是数据库问题，一停就停 2 小时甚至 5 小时。讽刺的是今天开始居然正式推永续合约产品线了，很好奇基础架构和撮合引擎这种水平怎么接永续合约。 我推断有两点，一是世界杯以后基本上团队是松懈了，按理说流量再大数据库压力再大，不可能比两个月前大吧；二是团队内部现阶段属于 ”创业果实瓜分阶段”，大概率是出现了一些利益分歧（比如公募变现还是私募变现问题），导致技术或者商业模块动荡交割，原来负责某块问题的人甩手掌柜了。 否则不能是如今这样。

其次要有一个直接面向终端产线、专门管理终端发布 yaml（比如 Kuberntes yaml/env config map 之类）的 CD server 作为 agent-based 开发流水线的终点。你可以面向 env 做很多数据抽象和归类，也就是更接近实际业务描述的 config map，降低碎片化的 env 配置和发布管理成本，以及配置出错概率。 这个 server 会不断 sync 最新 env 配置（即你的生产意图）到产线。并且每一次 agent 在发布流程中授权操作 env 变更都需要向你提供变更对象的 deeplink（这个 CD server 的基本功能），在 PR 评论区留档。你必须明确他改了什么，以及如果你以后自己操作要怎么改，在哪里改。 从 agent 管理哲学上来说，这个 server 是你传递实时意图到产线的关键。agent 不擅长处理紧急事务（比如 kill 开关），更擅长回溯与筹划，最终以及最敏捷的运维权利还是要放在自己手里。 ——这个是整件事能够高度自动化的关键。自动化不代表你放弃你该持有的掌控资源的权力，更不代表放弃你该担负的盈亏结果的义务。一旦放弃权利与义务（所谓的 agent 全委托），那么即使这个系统代码写得再好，到产线上也是一团散沙（这也是为什么有些 trading agent 在经济逻辑上根本不成立的原因，本质是跟单与 trust fund）。 这样你的机器才真正有可能成为你的器官、你的双手，成为你向市场表达交易意图的直接方式，而不是仅仅是你的一个活跃在你大脑以外的消息代理。

补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。 另外有几点小经验就是： 1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。 2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。 3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。

我认为如果我是早期 claude cli 和 codex cli 的作者，针对运维部分的训练我一定是会采纳大量 AWS/GCP 的官方和社区资料的。并且我的用户也不断在帮我 training 这些 AWS 产线上的运维经验。作为一个 agent provider，我对 AWS 这个语言体系下的所有变化都门儿清，坑也熟悉，因此能提供最高的问答质量和操作精度。 很多时候，用户端的交付，不是产品交付，而是经验交付。也不是技术的问题，而是市场磨合（用户持续验证）的问题。正如比特币和以太坊在各自领域不可替代一样，长时间高强度的市场验证，等同于产品质量和可信度。

我认为如果我是早期 claude cli 和 codex cli 的作者，针对运维部分的训练我一定是会采纳大量 AWS/GCP 的官方和社区资料的。并且我的用户也不断在帮我 training 这些 AWS 产线上的运维经验。作为一个 agent provider，我对 AWS 这个语言体系下的所有变化都门儿清，坑也熟悉，因此能提供最高的问答质量和操作精度。 很多时候，用户端的交付，不是产品交付，而是经验交付。也不是技术的问题，而是市场磨合（用户持续验证）的问题。正如比特币和以太坊在各自领域不可替代一样，长时间高强度的市场验证，等同于产品质量和可信度。

是的，就是需求端和观测端的优化，根据市场变化，根据需求目标和可用性目标定义出特定的监控指标。流水线运维标准和框架制定其实还都是一次性的，可以慢慢随需求规模改，就那么些东西。但真正滚动的还是还是获利和降损需求本身，要持续对市场敏感，那么系统的播报流、监控项、从日志聚合出的数据面板就要更精准有效，不能让自己失去对系统的感知。这一点上是 Kubernetes 和 Datadog 的价值，运维维度拆分得特别明确。

是的，就是需求端和观测端的优化，根据市场变化，根据需求目标和可用性目标定义出特定的监控指标。流水线运维标准和框架制定其实还都是一次性的，可以慢慢随需求规模改，就那么些东西。但真正滚动的还是还是获利和降损需求本身，要持续对市场敏感，那么系统的播报流、监控项、从日志聚合出的数据面板就要更精准有效，不能让自己失去对系统的感知。这一点上是 Kubernetes 和 Datadog 的价值，运维维度拆分得特别明确。

btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理： 1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。 2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段） 3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。 4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。 ——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。 而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”——PR 评论区就是最好的跨期开发对话记忆载体。

是的，github issue/pr 其实就是项目的外挂记忆/图书馆，本地一定要配置 gh （github cli，为了本地 agent 高效和 github 通信），如果我来写 coding agent 产品应该会把这东西 cache 进来吃透先来理解整个项目。PR merge 一定要走 squash merge，因为自动合成的 commit message 里会自带 PR/Issue ID，变向成为了注释指针。给 agent 简单通过 git blame 就能索引这个图书馆。

中国的青年才俊们组成的团队，很多时候就是一个随机的 idea 觉得自己团队要用（或者自己要用），但市场上没有什么现成的好用的就干脆自己重写一个，用得好了就干脆推广出去大家一起用。 于是一个小的 “side project idea” 就可能主导了一个新兴的赛道角落或者产品方向。纯粹的技术端算力过剩、技术人从自己需求出发，倒推到受众端和产品端。 就像梁老板说的，做了许多技术哲学层面更高维度的事情（LLM，AGI 之类），再看这些下游应用事务的处理是游刃有余的，to C 业务我们这几年赶都赶不走。

还是很难想象现如今只需要 7-10 个 Claude 账户（以用满每月每周的 Fable 额度为基准），仅一万人民币每月，就可以试探一个人的视角、开发和组织能力边界。 在自己的支付范围内，全力把这个劳动力杠杆开起来吧，没有比这件事更能在现如今称之为“套利”了。 你可以理解为资本市场现在在给当代人广撒空投，20x 套餐实际背后的token成本是可用工作额度（换算为同等劳动力价值）的 n 倍。 曾经创业（or 产品发布）需要花大功夫，甚至需要压上过去10年的积蓄以及未来 10 年的现金流，把一帮合作氛围恰到好处、各自领域的“能力者”拉拢起来，承接各类市场摩擦并且倚靠不稳定的人性构建一个有纪律章法的队伍——这事儿本身试错成本和赌注巨大。 现在你一个人能把绝大部分事情做到 90 分挑不出毛病，不依赖于外部，几乎不损耗现金流，从业结果其实是高度可预测的，高度和你自身挂钩的，“气运”的决定因素衰减。 大量视野广泛并且能对自己决策负责的人会从这个市场里“高度确定地”脱颖而出，没有人能拿“衰”（甚至出身）给自己做解释，必定是自己在担责和开拓能力上出了问题。

说说我是怎么管理这 7 个 cc 账户的，当单号用量满、被动切号时依然不丢失任何 token 工作量： 1. tmux 接入 cc harness 层（最关键） - tmux 最核心的作用是不让一个 bash 进程随着发起者主进程的关闭而关闭（可以认为 tmux 自身就是一层 harness），能够不让 cc subagent 发起的长工作流成为 cc 的子进程，不跟随 cc 换号/单套餐额度满导致的进程关闭而关闭。 - 新号恢复读取 tmux list-session 的时候直接从 cc harness 层直接读取 tmux session 索引，知道 cc session 和 tmux session 的对应关系，以便会话和工作量完整恢复。 - tmux log stream 要准确注入 cc harness 的日志吸收层，不要让 cc session 主动 fetch 日志，一方面是实时性不行，浪费控制层用量，一方面是可观测性，如果不把 tmux 接入 cc app background tasks UI 的话，后台的子任务进度基本是没法用的。 - 官方桌面端为什么不自己接 tmux，原因很明确，他们不希望自己的 session 脱离于自己的主进程管理。 2. cc harness 层对于单帐号的实时额度余量要有感知，三个时间维度的额度任意一个到达 95% 都发信号介入，保存会话，记录 tmux session 的关联，留下后任接手指南，随时准备下一个账户接管。 3. 后台要有一个脱离于 cc 的独立进程要时时刻刻同步多账号的对话历史（cc 桌面端是分账户隔离开对话数据的），必须保证重新登录能看到一模一样的东西。这个同步器也是可以扩展到 codex 的（当然有很多文本杂音要处理），双向同步会话历史，随时切换。 ——这几步做下来基本是不太可能让你用到额外的 api credit 的，最大程度在自用前提下控制成本，并且节省会话任务进度和时间。

Hyperliquid 也真是奇怪，上了 HIP-4 现在连一点维护市场 topic 的动力都无了，写一些创建和结算脚本很难么——想建别墅大连排，但只有沿街门面房的执行力。

很多人不知道，嘉信理财可以发放 Visa 借记卡，大陆一二线城市基本都可以 ATM 机直接取现 CNY，余额就是你的券商户头净值（如果你是杠杆账户还可以赊账），这个通道已经存在了十年左右，很难被打击。比很多 U 卡/信用卡的一棍子买卖要更有价值。