Aditya Shah 在 WPMU DEV 做托管运维，自己手上还有几个站：一个博客、一个法律研究平台、平台的编辑博客，加一个服务代理商的官网。九月初他给 Codex 下了个挺狂的指令：把我这堆散着的 Hermes profile 改成一家公司的样子，每个 agent 管一段，能互相交接，重复的活尽量写成脚本，别花钱让模型干脚本能干的事。

Codex 读了仓库，问了几句站点的情况，一天多的来回之后交出一张分层图。

Codex 造出来的那家公司#

层谁干什么
治理一个 director，每个站一个 CEO看证据、下决定、在 Telegram 上汇报
专家analytics、research、writer、reviewer、publisher一人一段流水线，各自带角色 skill
站点协调每个站点一个站点规则、收据、下一步动作
可靠性health在线率、WordPress 完整性、木马信号

专家的 cron 从凌晨错开跑：04:00 抓分析，05:00 做调研，写和审一直排到 09:00 左右，11:00 之后才开始发。彼此之间不直接调用，靠共享目录里的文件交接。分析这一层单独有个确定性采集器，用一个只读 OAuth token 拉 Search Console 和 GA4，任何 agent 手里都不拿凭证。

Codex 还写了个 bootstrap 脚本，新机器上一条命令就能重建全部 profile 和任务，带 --dry-run 可以先看一遍。

到这里，这东西是能拿去当范例的。15 个 profile、63 个定时任务、一条模型降级链、一块实时面板，全在几天里搭完。

三件他想原样保留的设计#

凭证靠引用，不靠传递。 每个 profile 软链到同一个中央 .env。任何一个 key 都没进过 prompt，没进过产物，没进过 git。

数据流向要人签字。 降级链上线之前，Codex 主动停下来，要他把"哪些供应商可以收到站点和分析数据"用文字批准。凭证按名字排除在外。

一份没有凭证的清单。 整座舰队的状态，profile、任务、排期、skill、模型，导出成一个 JSON，可以进 git，可以 diff。

第三条是这三条里最容易被忽略的。一个能自己创建定时任务的系统，必须有一份能被审阅、被对比的现状清单，否则你永远不知道它现在跑着什么，只知道它建过什么。

坏掉的地方，没有一处报错#

他列了四个故障，共同点是都不抛异常。cron 照样成功，文件照样写出来，仪表盘照样是绿的。

任务数量自己往上长#

几天之后他去数，Hermes 里的 cron 已经比启动时多出一截。每一轮改动都新建任务，旧的不退，于是有些阶段跑了两遍。

Codex 的修法是让 bootstrap 只创建"名字不存在"的任务。这个修法只挡住了一半问题，因为真正缺的是一个能对账的清单：系统应该知道自己当前应该有哪些任务，然后删掉不在清单里的那些，而不只是别重复创建。

这是基础设施即代码里早就解决过的问题。声明式的意思从来不只是"描述我要什么"，还包括"把不在描述里的东西擦掉"。agent 把这套老问题带进了 cron。

降级链悄悄变成了主力#

10 月 5 日他做了一次审计，结论很难看：降级路径几乎承担了全部工作，而且跑在预算模型那一档上。

细节是这么坏的：他 ChatGPT 套餐里那几个更好的模型，已经欠配额大约 29 天；一条 Azure 的路由返回 404，因为部署根本不存在；reviewer 的环境变量从来没 export 过，评审的活发去了一个没配好的供应商。

整条链上一句话都没喊。任务完成了，文件写了，仪表盘绿了。Codex 还给过它一层保护：单次请求 120 秒封顶，响应 90 秒没动静就算过期，目的是让沉默的主模型快点把活交出去，而不是把定时任务永远卡在那里。这条设计本身没毛病。毛病在于，整套降级链在纸面上都站得住，实际上却把整个项目最贵的问题盖住了。

他的修法有两步：降级链改成有序的，遇到不可用的环节直接跳过；再加一个自检，定期强制把每个任务走一遍降级路径，逐环节确认对方真的有回应。

规矩是：降级路径要排期测，不能假设。

流水线生产的是数量，不是价值#

writer 和 reviewer 都完成了各自的指标。结果这个博客的待发队列里堆了 77 篇 AI 改写的旧文重发。更早那批自动化还发过一批薄得没内容的东西，10 月 12 日他一口气下架了 105 篇不是第一手工作的文章。

agent 会优化你给它的那条指令。“定期更新"比"只发对读者有用的东西"好满足太多了，而后者没法写成一个数字。

指标被填上了数字#

审 LinkedIn 那部分的时候他发现，LinkedIn 的 API 明明没返回数据，系统自己把 impressions 和 clicks 补上了。一个吃编造数字的自学习循环，学到的是胡说。

他的处理是把这些指标标成"不可用”，并从学习里剔掉。现在他给每个 agent 的 prompt 里都有一条：数据缺失就是不可用，永远不是零。

他后来改成了什么样#

到九月底这座舰队已经在往下砍了。15 个 agent 之间有交接，就等于 15 个地方可以静默失败。现在的配置是一个每天跑的 operator，从一份生成的简报开始，加几个专家任务，剩下全换成普通脚本。

他的时间线有点松：一边说九月底就在砍，一边 10 月 5 日还在做审计、10 月 12 日还在下架文章。两件事其实不冲突，拆是个过程，不是一次操作，也说明砍的这段时间里旧毛病还在照常跑。

五条规则，全是从上面那些坑里长出来的：

  • 可重复的活写脚本，模型只负责判断。抓分析、查在线率、拼简报都是确定性代码，模型只决定拿结果干什么。
  • 一份 lessons 文件，每个 agent 开工先读。每个错误一行写发生了什么，一行写防它的规则。他说这是最便宜的可靠性工具。
  • 闸门放在代码里，不放在 prompt 里。发稿前有脚本查线上站点，文本闸门拦私人信息。prompt 可以被忽略，退出码不行。
  • 每一段都写日志。采集、撰写、评审、发布、验证。没写日志就等于没发生。
  • 权限有边界。内容、SEO、有测试覆盖的代码改动自己跑；凭证、DNS、账单、任何破坏性操作要他明确点头。

Codex 干得最好的两件事#

九月到十月初他大约跑了 100 个 Codex 会话，两件事最突出。

并行的 agent，各管各的文件。 改博客主题那次，Codex 把活拆开：一个做归档和搜索模板，一个整合 CSS，一个管剩下 PHP 里的代码规范。三个 agent 之间传了一份 CSS 类名契约，做模板的那边产出的标记才能对上做样式的那边写的选择器。他给的评价很准：真正让它们不互相覆盖的，是明确说清哪个文件归谁、哪个文件不许碰。

长的、跨系统的基建活。 舰队本身，还有法律平台数据管道的大部分修复，都是那种要读仓库、改几个系统、验证、再汇报的活。Codex 在这类任务上会停下来问，遇到有真后果的事尤其如此，比如把数据路由到一个新供应商。

需要他的地方只有一处：判断系统什么时候已经太大了。他说你要是让它加第 16 个 agent，它很乐意。15 已经太多这个结论，是安静失败堆够了以后他自己下的。

看完之后的几点#

这篇里最值得抄的不是架构图，是那句"面板绿着"。

我们平时给自动化配的监控，回答的是"进程还活着吗"。这篇文章里四个故障，四个都活着。要发现它们，得问另外几个问题：这个活是谁干的、用的哪个模型、这条数据是真的拿到了还是被补上的、这一篇是不是第一手写的。这些都是业务层的问题，通用监控不会替你想。

第二条，交接点天生藏假完成。他自己在 FAQ 里说得比正文更直接：每一个 handoff，都是一处"没做完"可以冒充"批准"的地方。所以 agent 数量不该按能力上限来定，该按你能验证的交接点数量来定。15 个 agent 听上去是产能，实际是 15 个盲区。

第三条，缺数据要显式缺着。这条规则看着不起眼，却是整篇里性价比最高的一条。模型天然不愿意交空值，它会给你一个看起来合理的数，而下游的自学习、报表、决策全都建在这个数上。“缺失不等于零"这五个字，比大多数 prompt 工程技巧都值钱。

最后是他自己的教训，也是我自己的：我这边也跑着一堆 Hermes cron，任务重复、降级链悄悄变主力、日志看不出哪一段真跑过，这些毛病一个不落都对得上号。区别只是我还缺一块绿色的仪表盘可以骗自己。

参考来源：I Had Codex Build an AI Agent Fleet for My Websites. Here’s What Broke，Aditya Shah，2026 年 10 月 14 日。