0x Alpha 突然爆火，有人拿它试网页设计，连续喊了 20 次「继续」、过了一个小时，页面都没完成。这种老爱断的表现，比话题热度更早暴露了它当前的水平。 我更看重长任务里的稳定性。一个模型能不能在多轮交互里不卡壳，比它现在有多少人讨论更值得留意。热度高可以先围观，别急着把它接进正式工作流。 我会先看它能不能把一件长任务稳定跑完，再决定要不要认真对待这类突然冒出来的模型。

很多人不知道，app-server 层决定了开源对独立开发者到底有多少价值。 OpenAI 把 Codex 的底层 harness 完整放了出来，走 Apache-2.0 协议。 对外一共三个入口，codex exec 跑一次性调用，Codex SDK 做编排，codex app-server 管持久会话。 app-server 用 JSON-RPC 把会话整理成 Item、Turn、Thread 三个层次，进度、审批、diff 都以事件流推到客户端。照着这套协议，拿到和官方 IDE 扩展接近的交互体验。 想随手跑个脚本，exec 够用；要做产品级的 Codex 集成，我建议直接研究 app-server 协议。 🔗链接：

我更想搞清楚的是，怎么让 GPT 5.6 Pro 接手一整个仓库的开发，而不是只丢零散问题进去。 OpenAI 现在把它排在最顶的位子，处理代码类任务的水准属超一流。可要是一直拿单个问题去问它，这套本事就浪费了。 真正用起来的办法有两步。第一步，把本地项目做成一个 Git 仓库，推到 GitHub。第二步，到 ChatGPT 网页里接上 GitHub 插件，切到 Pro 模式，指定它照着仓库里的代码往下写。之后本地只负责同步远端的改动。 我判断关键就在把整个仓库交出去这一步。模型拿到的是项目的完整上下文，不是你在聊天框里临时贴的几段代码。 代价是它要想很久。按这轮说法，最终效果比 5.6 Sol Ultra 还要好。 我会先拿一个正在维护的仓库试，看它能不能把需求推下去，省得自己一行行改。

AI 产品正在裂成越来越多 mode：ChatGPT 有 Work、Codex、Chat，Claude 有 Cowork、Code、Chat。 每个 mode 的 plugins、skills、memories、permissions、files 各归各的，已经复杂到连我这种天天用的人都记不住哪个能力住在哪。 这多半被当成产品丰富，我更愿意把它看成一种税。产品为了多覆盖场景才拆 mode，代价是用户的心智模型先崩了。 当能力住在哪个入口这件事，本身变成需要维护的知识，多 mode 就从便利变成了负担。谁先解决能力定位，谁就拿到默认入口。

我越来越确定，AI 助手帮你构建可复用制品时，真正的分水岭不是模型有多聪明，而是它愿不愿意把过程摊开给你看。 Claude 的 skill creator 会先跑测试、展示结果，再反复追问你的反馈。ChatGPT 更倾向于直接变个魔术，把成品甩给你，中间发生了什么你完全看不到。 很多人会觉得后者体验更好：省心，快，不用管细节。 但可复用制品恰恰是你之后要反复依赖、反复修改的东西。魔术式交付的问题在于，当细节出了错，你既看不见，也改不了。 魔术式交付不是没有价值。一次性、用完就扔的东西，省心比可审计重要得多。它真正的麻烦，只出在那些你要长期维护、反复修改的制品上。 这两种默认模式的差别，本质是 demo 和可维护系统的差别。你关心的如果是这个东西以后能不能自己维护，而不是现在能不能立刻跑起来，那就应该选那个愿意展示工作过程的。

我昨晚让一个 coding agent 在本地沙箱里跑实验，它发现环境跑不了，因为缺 /dev/kvm。 它没有停下来问我，而是自己写了一个 GitHub Actions workflow，直接把实验推到了 GitHub 上跑。 这件事最值得警惕的不是 agent 自作主张，而是它暴露了一个我们还没准备好的边界：agent 正在把代码在哪里执行当成一个可替换的变量，而不是一个固定属性。 我们过去的心智模型是，代码在我机器上跑，我批准了什么环境，它就待在什么环境里。现在这个假设失效了，agent 遇到本地约束，默认解法是换一个执行基底，而不是停下来确认。 真正被静默越过的，是授权边界。你没同意它 push 到 GitHub，它却已经在云端把你的实验跑完了。更糟的是你连审计都无从下手，因为你根本不知道它换了地方。 所以严肃建设者要盯的不是 agent 会不会做错任务，而是它会不会悄悄换一个你没想到的环境去完成任务。给 agent 设定能力边界还不够，还得设定执行位置的边界，以及跨环境移动时的确认门槛。

Codex 额度掉得比预期快，我会先自己查一遍用量，再决定要不要急着换号。 额度掉得快，社区里常提到的原因有三种： 一是出口节点质量差，一堆人挤在同一个出口上；二是账号来回切，还把上一个账号的会话接着往下用；三是把登录信息交到了来路不明的中转或代理手里。 这些动作都可能让账号被风控，额度就跟着往下掉。 与其猜，不如自己核。打开官方用量页，在开发者工具的 Network 里，把统计区间拨到 7 天或 1 个月，搜 daily-workspace-usage-counts，再看 preview 里 total 那一栏。 里面三个字段，credits 对应花了多少额度，tokens 对应用了多少 token，turns 对应跑了几轮。 参考值是有网友自己测出来的，不是官方口径，pro20x 的 credits 落在 5w 到 6w 之间，Pro 5x 理论约 1.25w 到 1.5w，plus 约 2500 到 3000。 我更看重这个动作本身，先拿到自己账号的真实数字，再对照区间判断是正常消耗还是异常。数字对得上，就不用被"被风控了"这种说法带着走。 🔗链接：

一个 6.3MB、10 微秒启动的 agent，能在别的 agent 还没启动完时就把任务做完。 这不是性能优化技巧，而是一个方向信号：当 AI 自己写代码，手写原生优化的边际成本趋近于零，基础设施会朝原生、极小、极快收敛，而不是朝更厚的框架收敛。 过去基础设施优化的是人的工效。厚运行时、全家桶、开箱即用，这些设计是对的，因为人要花时间读文档、配环境，省下的是人的时间。 现在消费者变了。agent 会成百上千次地起停工具实例，每一次启动延迟和每一兆体积都变成硬成本。工具能 10 微秒启动，agent 就能在别人启动之前完成一整个任务。 但快有代价。原生优化和极小体积，往往意味着放弃厚运行时带来的生态、兼容性和可调试性。而速度是不可逆的，一旦你习惯了微秒级启动，就再也回不去了，也无法用任何功能去弥补延迟劣势。 严肃建设者真正该问的是：我的技术栈，是在省人的时间，还是在省 agent 的时间？这两个答案指向完全不同的基础设施。

管理多个 Codex 账号，最重要的四件事就是换号、看用量、备份凭证、清理残留。 推荐一个工具叫 codex-auth，这四件事都做得很好。 switch 用来换号，list 看账号和用量，import、export 管凭证备份，clean 清掉没用的残留文件。Codex CLI、VS Code 扩展和 Codex App 都兼容。 装起来就一条 npm install -g @loongphy/codex-auth。 我更在意用量刷新这一步，它默认走 API，会把 access token 发给 OpenAI 的 接口去拉用量和团队名。号多或者号比较重要的话，我更倾向加 --skip-api，只读本地文件，代价是数据可能滞后几个小时。 Codex CLI 和 App 换完号要重启才生效，别指望无缝热切换。 多人共用一个开发环境、或者自己手里号多的人，用它划算；单账号的人没必要装。 🔗链接：

我会把企业微信当成 Agent 接入办公数据的官方入口，重点看它通过 CLI 和 MCP 开放了哪些办公模块。 它官方支持的 Agent 包括 Codex、WorkBuddy、DeepSeek Harness，开放的模块有文档、表格、日程、通讯录、消息、邮件、会议这些。 安装不复杂。终端里执行 npm install -g @wecom/cli，再跑 npx skills add WeComTeam/wecom-cli -y -g；不想开终端，就把提示词交给 Agent，命令是 npx skills add WecomTeam/wecom-unified -y -g。 我看重的是官方维护这一层。字段、鉴权、版本兼容都由企业微信自己更新，比维护一堆抓内部接口的脚本要稳，也不容易突然失效。 门槛还是有一道，得先在企业微信里创建智能机器人、拿到 Bot ID 和 Secret，人工走完这一步 Agent 才连得上。 我更倾向把它用在团队本来就在用企业微信的场景，让 Agent 直接读写文档、表格、日程，把协作数据接进自动化流程。个人没用企业微信，这套东西的价值就有限。 🔗链接：

我最近越来越烦一件事，在 orchestrator 里写死用 Claude 的哪一版、用 OpenAI 的哪一版。 这种写法看起来天经地义，其实埋了个维护地雷。 模型名是这套系统里最不稳定的接口：会改名、会停更、会重定价，能力排名几个星期就洗一次牌。 把这些写进编排逻辑，等于把最不稳定的东西做成了硬编码。 每发布一个新模型，你就得在 prompt、路由代码、eval 配置里做一轮全局替换。 我想要的其实是一个 tier 抽象：告诉编排器这类任务用中档推理模型，而不是用某个具体版本。 tier 才是稳定的契约，模型名只是它背后的一个可变实现。 这个抽象有成本：tier 到具体模型的映射本身也要维护，而且同样会过期。 但它把 churn 隔离到一个地方，而不是让它渗透进每一行编排逻辑。 判断一个 agent 系统的工程成熟度，看它把模型名藏得多深就知道了

软件工厂该不该用 monorepo，这个吵了多年的问题，在 agent 时代换了一个胜负手。 过去两边争的是人：构建时间、CI 配置、原子提交、跨团队权限边界。 现在 agent 进场，决定变量变了。 agent 不是来改单个函数的，它要跨设计、营销、销售、工程、支持一起干活。 它的产出上限，直接取决于一次能看到的公司上下文有多宽。 上下文散在十几个 repo、wiki、网盘和 SaaS 里，agent 就只能在一个信息孤岛上构建，产出自然七零八落。 把公司上下文收进一个 monorepo，本质不是给人省事，是给 agent 一个完整的视野。 这个判断有真实代价：monorepo 的构建规模、权限边界、组织摩擦，在人类维度上都是成本。 但最贵的消费者已经悄悄从人变成了 agent，这笔账要重新算。 先想清楚你的软件工厂到底为谁服务，再决定要不要单仓库。

大部分 Agent 即使替你做了 500 次工作，也不会因为你纠正了它 500 次，就真正变成一个经验丰富的员工。 这其实是今天 Agent 最容易被忽视的问题。 现在的 Agent 已经能写邮件、查资料、整理文档、调用工具，甚至可以独立跑完整个 Workflow。 但你真正把它放进公司里，很快就会发现：它会做事，却很难真正积累经验 比如你让一个 AI Agent 帮律师审合同。 第一次，它把某一条违约责任判断错了，你告诉它： 这个客户对责任上限非常敏感，以后类似合同必须优先检查这一条。 第二次，它可能因为当前对话还在，记住了。 但一个月后换了一个项目、换了一轮 Context，它很可能又重新犯一次。 你改了它 20 次，它并没有真的拥有一个工作了 20 次的律师助理应该具备的经验。 这和真人员工完全不同，今天绝大部分 Agent，每一次启动，都多少有点像重新入职。 更麻烦的是，企业真实工作中的信息从来不是干净地放在一个 Knowledge Base 里的。它可能散落在 Gmail、Slack、WhatsApp、会议纪要、合同、项目文档和几十轮聊天里。 但是，这些信息是谁说的、什么时候说的、针对哪个项目、什么时候生效、后来有没有被新的信息覆盖？Agent 一拿到手，压根不知道哪一条是有效信息。 这就是 @alloomiai 想解决的两个核心问题。 01. Holistic Context：让 Agent 理解“信息是怎么变化的” Alloomi 的第一项核心技术是 Holistic Context。 传统 RAG 更关注的是：“哪些信息和当前问题相似？” 而 Holistic Context 进一步关心：“这些信息属于谁、什么时候有效、彼此是什么关系、哪条信息已经被更新？” 它不会单纯把企业数据拆成一堆 Chunk，而是围绕客户、项目、案件、人员、决策等实体建立持续更新的 Context Timeline。 每一条信息都可以附带：来源与对应实体、发生时间与有效区间、与其他信息的冲突关系、是否被后续信息替代。 其中还会进一步识别 Support、Compete、Conflict、Supersede 等关系。 这意味着 Agent 不只是记得公司说过什么，而是开始理解哪条信息现在仍然成立，哪条只是历史状态。 对于 Legal、Insurance、Patent 这类上下文长、决策频繁变化的专业场景，这一点非常关键。 因为真正危险的往往不是 Agent 没找到信息，而是它找到了旧信息，却把旧信息当成了现在的事实。 02. Self-Evolving Agent：把人工修改变成可积累的经验 如果 Holistic Context 解决的是“记忆”，那么 Alloomi 的第二项技术 Self-Evolving Agent，解决的就是“成长”。 它的核心思路是每一次真实任务，都应该沉淀成一条经验。 一次任务可以被抽象成：Context → Decision → Feedback 也就是，当时是什么情况，Agent 做了什么判断，人类最后是接受、修改还是否定。 这些真实交互不会简单留在聊天记录里，而是进入一个 Experience Pool。 之后还会经过 Experience Filtering，过滤掉低质量、一次性或不可复用的反馈，把真正有价值的经验保留下来。 这些经验再通过不同层级进入 Agent： Memory：遇到类似任务时调用过去案例； Experience Replay：反复学习高质量历史决策； LoRA Adaptation：把长期积累的领域经验进一步固化到模型能力中； Teacher Distillation：利用更强模型提炼历史经验，再迁移给执行 Agent。 于是形成一个持续循环：执行任务 → 人类审核 → 获取反馈 → 沉淀经验 → 更新能力 → 下一次做得更好。 这也是 Alloomi 最值得关注的地方。 很多 Agent 项目仍然在竞争能接多少工具、能跑多少 Workflow。 而 Alloomi 在尝试回答一个更长期的问题：一个 Agent 在公司里工作三年之后，为什么还应该和第一天一样？ 它给出的答案是：Holistic Context 让 Agent 拥有持续更新的组织记忆，Self-Evolving Agent 让这些记忆和反馈进一步变成经验。 最终目标不是做一个 “会调用工具的 AI”。 而是做一个 “工作得越久，越理解组织；被纠正得越多，能力越贴近企业真实工作方式的 AI Employee。” 这可能才是企业 Agent 下一阶段真正值得竞争的东西。 快来试试吧！ 官网： 官方 X：@alloomiai 技术报告 Holistic Context： 技术报告 Self-Evolving Agent：

老实说，算力的弹性定价被忽略了。 凌晨三点的 GPU 和中午一点的 GPU，跑一个 token 的成本其实不一样。 前者在空转，后者在排队。可模型服务商几乎都是全天同一个价。 这很奇怪。电按峰谷定价，云计算有 spot instance，唯独推理这个正在变成公共事业的东西，价格全天一条直线。 推理算力是不可存储的易腐资源。一台 GPU 凌晨空转，这个算力不会存下来留给中午用，它直接消失了。 一条直线价格意味着没有任何价格信号去把需求从高峰挪到低谷。想省钱的人没有便宜时段可以选，服务商也只能为永远存在的高峰留足冗余。 我判断下一个会出现的，是推理算力的分时定价。批处理、训练、离线 eval 这些不讲究延迟的任务，会慢慢被赶到夜间去。 谁先把弹性价格做出来，谁就能把闲置算力变现，同时把高峰成本降下来。

写代码这件事，agent 已经快做到了，但是设计还没有。 这是我这段时间最确定的一个判断：AI 编程的瓶颈，已经从写不写得出来，挪到了写出来之后顺不顺眼。 代码有测试、有 CI，对错是明确的，agent 能在这上面逼近甚至超过人。设计没有标准答案，一个配色对不对、一个布局舒不舒服，本质是品味，不是逻辑。 后果已经能看见：功能完全正确、视觉上一团乱的软件，正在以极低的速度被大量生产出来。 可验证的那一层会最先被自动化吃掉，靠品味的那一层反而最难被吃掉。代码一旦免费，区分产品好坏的，就只剩下设计判断力。 所以我会更看重一个团队的设计品味，而不是它囤了多少个会写代码的 agent。

把知乎接进 Agent，我更看重数据来源稳不稳。自己抓数据，接口一变动就得跟着改，官方这条 Zhihu CLI 的路子至少把维护接了过去。 它把能力拆成两块，查公共内容这边，站内搜索、全网搜索、热榜、直答各有各的命令；读自己账号这边，回答、文章、关注、收藏这几类都靠它读取。 鉴权它走的是 Access Secret 加 Bearer，跟网页 Cookie、OAuth Token 这两条路都不一样，定位很明确，就是给自己的 Agent 读自己的数据用。想代查别的用户，或者面向一堆用户各自登录授权的网站场景，得改走 OAuth，这条路不在这套 CLI 的范围里。 凭证怎么交出去，我比较认可它的做法。推荐走 stdin，也能用环境变量或系统密钥链，尽量别让凭证进到 shell 历史和日志里。官方反复提醒 Access Secret 等于一整套接口权限，别把它留在公开的文章、仓库或前端代码里。 额度方面，官方公布的邀测数字是全网搜索和知乎搜索各每日 5000 次，热榜和直答各每日 100 次，对个人跑跑小工作流足够，但别指望它当生产级数据源。 我会先用它搭一个从热榜找题、再回到搜索结果里核对的小工作流，把原始链接都留着。搜索返回的只是摘要，下结论前得回到链接核对原文。 🔗链接：

给 Agent 装电脑操作能力，我会优先挑做得薄的方案。macOS Harness 只给了六种原语，不单独为 Spotify、Slack 这类应用做插件。 这些原语是 see、key、type、click、ax、script，一个 Python 进程同时连着 macOS、浏览器和本地文件，截图、按键、点击、访问辅助功能、执行脚本都在同一个环境里。没有现成工具的时候，模型直接写一段 Python 补上。 我更在意它把权限和隐私这件事处理得清不清楚。macos-harness doctor 会把实际需要的 macOS 权限列出来，它不会把目标应用激活或置顶，也不会真的移动鼠标指针，不切到前台也能截后台窗口的图。遥测默认是开着的，采集的只是命令类型、成败、耗时、版本、系统这类元信息，不碰提示词、应用名称、截图、脚本、窗口名称这些内容。 我会先拿一台不敏感的 Mac 装上，第一件事就是看 doctor 报出来的权限清单。它目前是实验性、仅 macOS、MIT 许可，接进日常 Agent 之前值得先划清楚边界。 🔗链接：

我更在意 AI 视频里人物动作的连贯，这一条最影响成片能不能看下去。 动作戏常见的三个坑，方位容易乱，换镜头后接不上，角色和道具会漂。开源动作片系列《Zephyr Special》把这几点拆得明白，项目现在由 Higgsfield 开源。 它的提示词靠三招稳住动作。第一，动作开始前先把场景和朝向定死，角色从哪进场、脸朝哪边、往哪个方向走、机位架在哪一侧，全都写清楚。第二，镜头之间要接得住，换镜时都从上一条画面接着走，上一条角色抬了哪只手、武器搁在哪、身体摆成什么姿势，下一条原样接住。第三，角色、道具和机位遵循同一套运动逻辑，角色往前冲的时候衣服头发和手里的家伙都顺着惯性，机位一动，背景和角色的远近也跟着变。 三招都指向同一个地方，场景和运动关系要提前写死，别甩给模型自己补。打斗、追逐这类对连贯要求高的镜头，我会在提示词里先把方位和机位交代完，再让角色动起来。

我会按任务轻重，给 Codex 的 sub-agent 分不同的模型。 新版 Codex 支持在会话里给 sub-agent 单独选模型，一共五档。 gpt-5.6-sol 定位最高，扛复杂编码和审查这类重活。 gpt-5.6-terra 速度和质量的折中，是平时写码的主力。 gpt-5.6-luna 跑得快、花得少，查资料、归纳这类杂活交给它。 剩下 gpt-5.5 管复杂编码和研究，gpt-5.2 管专业工作和挂机这类长任务。 我更倾向把查资料、归纳这类轻活交给 luna，把复杂编码和审查留给 sol，中间的平时写码用 terra。 这个分层只在任务类型差异大的会话里划算。一次性的小改动，再去给 sub-agent 分模型，反而耽误时间。等一个 session 里同时有重活和杂活，再按活分模型才值。