Glen Phoenix

Exploring AI-native software, agent skills, and reusable LLM runtimes. Building in public and open-sourcing what works.

[Glen Phoenix @Glen56121]

@bylixing @poteto 我5个主脑(manager agent)，注意力就分配不过来了，3个平时工作用，2个在家里自己跑自动化任务，还要向博主多多学习

[Glen Phoenix @Glen56121]

@bylixing @m4rs0n2 看完了，8月份就写出了这样的实践文章👍，内容很值得学习和研究

[Glen Phoenix @Glen56121]

@yyf940515 原来如此，简单来说就是让 manager 只看结果和 worker 的执行日志，这样确实可以减少大量的上下文读取 token

[Glen Phoenix @Glen56121]

最近大家都在聊 Loop Engineering，我这几周其实一直在跑一个。

不是让 AI 一次写完，而是：执行 Agent 写代码 → 经理 Agent 审查 → 发现问题打回 → 带着具体缺口返工 → 再提交。

讲个真实的例子。

一次部署卡在文件校验：大部分文件都过了，只有一个运行时数据库没过哈希检查。

第一轮，经理 Agent 把问题交给执行 Agent 去诊断。它没有只盯着"这个文件为什么不一致"，而是多走了一步：发布包里是不是混进了本不该当成固定基线的运行态数据？除了数据库，还有运行时生成的身份文件。它也说清楚了，这轮没碰现场，也没替换数据库。

我当时提了两个方向：取消这个检查，或者恢复成旧数据库。经理 Agent 没有直接执行，而是先把两类东西分开：一类是该校验完整性的交付内容，一类是运行后本来就会变的现场数据。恢复旧库可能覆盖现场的变化，也没解决"校验范围定错了"这个根本问题。

第二轮，方案变成：保留现场数据，调整运行态目录的校验范围，镜像、脚本、配置继续校验。执行 Agent 拿到的也不是"把问题解决"，而是一个有边界的任务：只改交付目录和校验逻辑，不碰现场。

这就是我理解的 Loop：不是让 AI 无限重试，而是每一轮都带着新判断进入下一轮。

它也不是全自动的，关键取舍还是我拍板。但我不再需要每一轮都亲自推着它走。

你现在是让另一个 Agent 审查结果，还是自己逐个检查？

[Glen Phoenix @Glen56121]

用 codex-team-runtime 跑了 9 个 Agent 开发服装系统，累计 54.7 亿 Token。

最费的居然是不写代码的 Manager（Astra），占 26%，因为审查结果时要读大量上下文。

做多 Agent 编排的朋友，你们怎么控 Manager/Reviewer 的上下文消耗？
1.摘要交付？
2.独立便宜 Reviewer？
3.还是靠 CI 自动验收？

[Glen Phoenix @Glen56121]

@yyf940515 这个点很准。我回去查了下自己的 Harness：Manager 和 Worker 是独立窗口，模型也分了层，但规则里还允许 Manager 读 Worker 的详细对话。职责分开了，上下文没隔离。

想请教一下：像"不碰现场"这种过程约束，你是怎么在只看结果的前提下验收的？

[Glen Phoenix @Glen56121]

我的一个 AI 开发团队，某一天记录到的 Token 用量是 435,239,712。

四亿多。这是已采集的用量，不是账单金额，但足够说明：当 AI 从"帮你写一段代码"变成"一支团队持续干活"，Token 就不是零头了。

很自然的想法是：Manager 用最强的模型，因为需求判断、拆分、验收错了，后面全白干；Worker 用便宜的模型，做边界清楚、能验证的执行。

但账单不一定按直觉走。拆成团队会多出看不见的开销：Manager 要把任务讲清楚，Worker 要重新理解上下文，提交后要审查，一旦返工双方再耗一轮。我画过一笔示意账（虚构单位）：单一强模型 100；分层团队返工少，80；返工多，110，反而更贵。

所以什么活交给便宜模型，要先看任务本身。

举个例子：给查询接口加一个筛选参数。如果 Manager 只说一句"加个筛选参数"，Worker 就得自己决定空值什么意思、默认行为、分页怎么办、旧调用兼不兼容。便宜的执行环节里，藏着一段没做完的需求设计。Manager 的强，应该花在把这些先讲清楚上。

最近一个真实体验：我单独用较轻量的 Luna 模型做镜像打包，两次分别是 5 分 51 秒和 4 分 44 秒，速度和效果都符合预期。不是对照实验，但说明流程成熟、结果好核验的活，不需要最强的模型。

下一步我在做模型路由：团队默认准备三档 Worker，由 Manager 按任务挑。
· Luna：流程固定、好核验，比如按脚本打包
· Terra：范围清楚，但需要一定排查判断
· Sol：不确定性高、跨模块权衡

遇到搞不定的情况，Worker 不无限重试，而是把产物、错误和诊断交回 Manager，由它决定要不要升级模型。流程稳定后，同类任务再回到 Luna。

我追求的不是单次调用最便宜，而是一次合格交付的总成本最低。

你的团队现在怎么分配模型？全用最强的，还是会分档？

[Glen Phoenix @Glen56121]

@AI_Jasonyu 已经收到短信了，感谢，请问下后续如何续费？

[Glen Phoenix @Glen56121]

Worker 开得越多，交付就越快吗？

一次真实的固件升级开发让我改变了想法。

需求是做固件升级，支持在线和离线两种方式。和 Manager 讨论完，它发现要同时改三个项目：设备侧、平台服务、前端页面。于是建了 3 个 Worker：

· 下游 Worker：文件准备、协议字段、指令下发和防重复
· 平台 Worker：公共任务、进度日志、HTTP 接口
· 前端 Worker：在线和离线页面、上传、轮询、日志展示

注意，它是按项目拆的，不是按"在线升级""离线升级"这种功能拆的。在线和离线共用很多代码，按功能拆，两个 Worker 很可能同时改同一段公共逻辑，最后互相覆盖。按项目拆，每块代码只有一个负责人。

最让我意外的是下一步：Manager 没有马上让大家开工，而是先让 3 个 Worker 互相确认接口和边界。升级任务 ID 谁生成？进度状态谁维护？前端怎么查进度？重复下发在哪一层拦？每个 Worker 从自己的模块出发，说清楚"我需要什么、我能提供什么"。对齐之后，才一起开发。

这就是靠谱的技术负责人会做的事，只是这次开对齐会的是几个 AI。

并行也不是免费的。我为了说明道理算过一笔示例账（不是实测）：3 个独立模块，一个 Worker 顺序做大约 75 分钟、8 万 Token；三个并行大约 40 分钟、9 万 Token。快了 35 分钟，多花了 1 万 Token。并行买的是时间，付的可能是 Token。

我现在的节奏是：先对齐共同前提，再并行实现，最后集中整合和验收。

决定交付速度的，不是开了几个 Agent，而是它们什么时候可以一起动手。

你会让多个 Agent 同时改代码吗？最担心的是什么？

[Glen Phoenix @Glen56121]

AI 写代码已经够快了，真正乱的是协作。

接口刚改完，前端还在等字段确认，构建又报了错。你在同一个对话里补需求、查错误、追问上一个改动验证了没有。对话越拉越长，等你想问一句"现在到底卡在哪"，自己都得先翻半天。

所以我做了一件事：把 Codex 的一个对话，拆成一支有分工的 AI 开发团队。

· Manager：确认需求、拆任务、协调依赖、安排返工、做验收
· Worker：每个都是独立的 Codex 任务，在约定范围内写代码、跑测试，交回改动和证据
· Liaison：负责日常沟通，我想知道进度就问它，不打断 Manager

我最看重的一点是：每个 Worker 都是我能打开的真实窗口。它选了一条我没想到的实现路径，我可以当场问为什么；它理解错一个字段，我马上纠正。人的参与从"最后验收"提前到了"执行过程中"。

做的过程中踩过一个坑：光在提示词里写"你是 Manager"不够。对话一长、上下文一压缩，AI 会忘了自己是谁。Worker 改完代码只在自己窗口说一句"做完了"，没向 Manager 交付。

后来我把"我是谁、属于哪个团队、向谁汇报"持久化下来，AI 忘了可以查回来；任务状态也单独记录：执行中、已提交、审查中、返工、已通过。

还有一个很像真实团队的规则：Worker 已提交但没通过验收，系统不会因为它窗口闲着就塞新活。窗口闲着和活干完，是两回事。

目前我同时跑过 3 个团队、十几个 Agent，持续一个多月，没遇到我察觉到的团队记忆丢失。这是使用观察，不是测评数据，项目也还在开发中。

你用 AI 写代码时，最乱的是哪一步？

[Glen Phoenix @Glen56121]

AI already writes code fast. What falls apart is coordination.

The API just changed, the frontend is waiting on a field decision, and the build is failing. You keep piling requirements, error logs and "did you verify that?" into one chat. By the time you ask "where are we actually stuck?", you have to scroll back through everything yourself.

So I split a single Codex chat into an AI dev team with real roles:

· Manager: clarifies scope, splits tasks, coordinates dependencies, sends work back, accepts results
· Workers: each one a separate Codex task that builds and tests within an agreed scope, then hands back changes plus evidence
· Liaison: answers "where are we?" so I don't interrupt the Manager

The part I care about most: every Worker is a real task I can open. If it picks an approach I didn't expect, I ask why on the spot. If it misreads a field, I correct it right there. I get involved during execution, not just at the end.

One lesson learned the hard way: writing "you are the Manager" in a prompt isn't enough. After long chats and context compaction, agents forget who they are. A Worker would finish the code, say "done" in its own window, and never hand it to the Manager.

So team identity ("who am I, which team, who do I report to") is now persisted and can be looked up again. Task state is tracked separately: executing, submitted, reviewing, rework, approved.

And one rule that feels very much like a real team: a Worker whose submission hasn't been accepted doesn't get new work just because its window looks idle. An idle window is not finished work.

So far I've run 3 teams and a dozen-plus agents for over two weeks without noticing any team memory loss. That's an observation from real use, not a benchmark, and the project is still in development.

What's the messiest part of coding with AI for you?

[Glen Phoenix @Glen56121]

@AlanShao111 AI 是现在最好玩的游戏 每天必须 vibe coding

[Glen Phoenix @Glen56121]

Gemini used to be my most-used AI. Then GPT-5.4 and Opus 4.6 came out, and I quietly stopped paying for Google One.

Now Gemini 4 Argon shows up on the Artificial Analysis index at 53, tied for 3rd, but it's not even publicly available yet.

Ship it, Google. You might win me back. 👀

[Glen Phoenix @Glen56121]

One developer. Multiple AI teams. Here’s how I work with them.

I’ve been using Codex Team Runtime for over a month, working with three teams and more than a dozen agents.

Each team has a Manager coordinating the work and Workers executing in separate conversations. Independent tasks can move forward in parallel.

I can discuss an implementation with one Worker, check another team’s progress, and bring changes in direction back to the Manager. I’m part of the work—not just waiting for a final result.

The useful shift is from one long chat holding everything to several teams with continuing responsibilities.

Keeping that useful over weeks takes more than launching agents. When conversations pause or get compacted, the team needs to recover who owns the work, what remains unfinished, and what needs review.

That’s the connection to my broader research into agent runtimes.

I wrote up the workflow, real screenshots, trade-offs, and what still needs work:

[Glen Phoenix @Glen56121]

https://t.co/kUS1Yt9Wv9

[Glen Phoenix @Glen56121]

https://t.co/kUS1Yt9Wv9

[Glen Phoenix @Glen56121]

https://t.co/JrdT7vUYyV

[Glen Phoenix @Glen56121]

https://t.co/6naTJbyJU4