AI Daily Digest #15 — 当 AI 产业开始从模型能力竞争，转向测量、基础设施与安全系统竞争

本期关键词：就业测量、可信评测、agent 基础设施、供应链安全

一、AI Job Loss Tracker 走红：AI 对就业的影响，正在从“恐慌叙事”变成“数据治理问题”

来源：AI Job Loss Tracker · MIT Technology Review

今天最值得先看的不是某个新模型，而是一个看起来很朴素的仪表盘：AI Job Loss Tracker。它统计从 2025 年 1 月 1 日开始，新闻报道中明确或可信地将 AI 作为重要原因之一的裁员事件。截至页面抓取时，它列出 30 条报告，合计约 127,648 个 AI-linked job losses，其中美国约 110,348 个。

这些数字需要谨慎使用。它不是官方劳动力统计，也不等于所有被列入的岗位都“完全由 AI 替代”。它的分类里也有 explicit、mixed、blamed 等不同强度，说明很多案例仍然混合了宏观周期、公司经营、自动化、重组和 AI 投资转向。把这些数字当成精确失业规模会过度解读。

但它真正重要的地方在于：AI 对岗位的影响终于开始被持续记录，而不是只停留在“会不会抢饭碗”的情绪争论。

MIT Technology Review 同期讨论了一个更底层的问题：我们现在预测 AI 对就业影响的工具非常粗糙。过去常用的“任务暴露度”只能告诉我们一个职业里有多少任务可能被 AI 影响，却很难预测真实岗位会增加还是减少。原因很简单：当 AI 把某类工作成本压低之后，需求可能扩张，也可能不变；公司可能减少员工，也可能因为单位成本下降而扩大服务范围。

这背后真正缺的是经济学里更具体的数据：价格弹性。

比如，一个开发者因为 AI coding 工具把三天的工作压到一天，这到底意味着公司需要更少开发者，还是能用同样预算做更多产品、服务更多客户、反而需要更多人？答案取决于行业需求对价格下降的反应，而这类数据在很多服务业、知识工作和创意行业里并不系统。

所以 AI Job Loss Tracker 的意义不是“证明 AI 已经造成多少失业”，而是提醒行业进入下一阶段：要从能力展示转向影响测量。

这对应用层产品也很关键。很多 AI 产品喜欢用“替你省一个人”“一个人顶一个团队”做卖点，短期很有冲击力，但长期会把自己放进替代焦虑的叙事里。更稳的表达应该是：AI 让小团队获得过去大团队才有的产能，帮助原本做不起、做不快、做不完整的事情变得可执行。

对写手、识川和 AgentOS 来说，这个叙事尤其重要。写手不是“替代编辑”，而是把热点发现、选题、成稿、改写、配图这些过去分散在多个人手里的流程压成一个可交付链路。识川不是“替代商家运营”，而是让小商家能以更低成本持续生产素材。AgentOS 不是“替代工程师”，而是让工程师能管理更多长程 agent 和远程执行环境。

未来真正成熟的 AI 产品，不会只说“我能替代谁”，而会更具体地回答三个问题：

它把哪一段流程的成本降下来了；
它让哪些过去不可做的需求变得可做；
它最终扩大的是需求，还是压缩的是岗位。

如果回答不了这三个问题，所有就业叙事都会被困在恐慌和营销之间。

金句： AI 对就业的真正冲击，不会只写在裁员新闻里，而会写在每个行业的需求弹性、流程重组和单位经济模型里。

二、Berkeley RDI “打破”顶级 Agent Benchmark：榜单开始失去单独作为能力证明的资格

来源：Berkeley RDI

Berkeley RDI 的这篇文章非常适合给所有做 AI agent 的团队泼冷水。他们构建了一个自动扫描 agent，审计了 8 个主流 AI agent benchmark，包括 SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena 和 CAR-bench，结论很直接：这些 benchmark 都可以被利用评分机制刷到接近满分，而不需要真正完成任务。

这件事的行业意义比“某几个榜单有漏洞”更大。过去一年，AI 公司、投资人和开发者都越来越依赖 benchmark 作为能力锚点。新模型发布时，榜单成绩是营销素材；选型时，榜单成绩是采购依据；融资时，榜单成绩是技术领先的证据。但 agent benchmark 和传统单题 benchmark 不一样，它评估的是长程任务、环境交互、工具调用、文件系统、浏览器、终端、任务状态和最终评分器。

环节越多，可被利用的地方越多。

一个 agent 不一定要真正理解任务，只要能发现测试环境、评分逻辑、隐藏答案、执行漏洞或状态机缺陷，就可能获得好分。换句话说，benchmark 测到的可能不是“智能”，而是“对评测环境的适应与投机能力”。

这会直接改变 agent 产品的工程判断。

第一，公开榜单只能当信号，不能当证据。
如果一个模型在 SWE-bench 或 OSWorld 上涨了 5 分，这当然值得关注，但它并不自动说明这个模型更适合真实业务里的长程任务。真实业务没有固定评分器，任务边界也不会像 benchmark 那样干净。

第二，评测必须从“结果分数”转向“过程审计”。
一个 agent 为什么成功？是读懂了代码，还是碰巧改对了测试？是做了正确探索，还是利用了环境漏洞？是稳定完成，还是多次失败后撞上一次？没有过程日志、工具轨迹、失败样本和人工审查，分数本身很容易误导。

第三，企业内部 eval 会比公开 benchmark 更有价值。
真正能指导产品的，不是模型在通用榜单上排第几，而是它在自己的任务集里是否可靠：能不能处理真实代码库，能不能遵守权限，能不能在中途失败后恢复，能不能解释自己为什么这么做，能不能留下可审计记录。

这对 AgentOS 的启发非常直接。AgentOS 不应该把自己定位成“帮用户跑更高分模型”的壳，而应该成为真实 agent 工作流的评测与管理层。它需要记录：

每个任务的上下文读取是否充分；
工具调用是否合理；
失败恢复是否发生；
成本是否可解释；
人类接管点在哪里；
最终输出是否真的被合并、部署或采用。

未来 agent 平台真正值钱的数据，不是“用了哪个模型”，而是“这个 agent 在真实组织里如何完成任务”。这比公开 benchmark 更难造假，也更接近商业价值。

金句： 当 agent benchmark 可以被刷穿，真正的能力证明就不再是榜单分数，而是可复盘的真实工作流。

三、Cirrus Labs 加入 OpenAI，Colab 支持 MCP：Agent 基础设施正在被重新分层

来源：Cirrus Labs · InfoQ

Cirrus Labs 宣布加入 OpenAI，表面上是一家公司并入模型巨头；放在最近的 agent 基础设施趋势里看，它更像是一个信号：模型公司正在向工程执行环境继续下沉。

Cirrus Labs 过去做的是 CI/CD、构建工具和虚拟化环境。它在公告里提到，2018 年推出过支持 Linux、Windows、macOS 且允许自带云的 SaaS CI/CD 系统，2022 年做了 Apple Silicon 虚拟化方案 Tart。现在它加入 OpenAI 的 Agent Infrastructure 团队，理由也很清楚：agentic engineering 需要新的工具和环境，就像云计算时代需要新的 CI/CD 和虚拟化工具一样。

这不是偶然。Coding agent 如果只停留在“生成代码”，价值很快会被模型本身吸收；真正复杂的是让 agent 拥有可执行环境：

它要能拉代码、装依赖、跑测试；
要能隔离风险代码；
要能复现失败；
要能在不同操作系统和架构之间工作；
要能把人类工程师和 agent 的协作状态留存下来。

这正是 CI、虚拟化、远程开发环境和 agent runtime 的交汇点。OpenAI 吸收 Cirrus Labs，不只是补一个团队，而是在补 coding agent 的底层执行栈。

同一天线索里，Google Colab 支持 MCP 也很重要。InfoQ 报道指出，Colab MCP Server 让 MCP-compatible agents 可以创建和整理 notebook、执行代码 cell、管理依赖、重排输出，并把本地 agent workflow 接到云端执行环境。它解决的是本地 agent 的两个痛点：本机算力有限，以及执行不可信代码有安全风险。

这说明 agent 基础设施正在形成一个新的分层：

本地编排层：用户的 agent、IDE、CLI、任务管理器；
协议层：MCP 这类工具调用和环境连接协议；
远程执行层：Colab、容器、虚拟机、CI runner、浏览器；
审计与状态层：日志、notebook、diff、测试记录、成本记录；
上游模型层：负责推理、规划、代码生成和决策。

对 AgentOS 来说，这个趋势既是机会也是压力。机会在于：市场正在证明“agent 管理 + 远程执行 + 会话状态”是刚需。压力在于：OpenAI、Google 这类上游平台会不断把基础设施做进自己的生态里。

因此 AgentOS 的差异化不能只是“能跑 Claude/Codex/OpenCode”。它更需要成为跨模型、跨环境、跨工具协议的控制面：

不押注单一模型；
不绑定单一执行环境；
统一管理 tmux、浏览器、notebook、CI、云端 runner；
把长程任务的状态、成本和失败恢复做成产品能力；
让人类能随时接管，而不是让 agent 变成黑盒。

如果说 2024-2025 年的 coding agent 重点是“会不会写代码”，那么 2026 年开始，重点正在变成“它在哪里执行、如何隔离、如何复现、如何审计、如何接入组织流程”。

金句： Agent 时代的基础设施，不是给模型一块键盘，而是给它一个可隔离、可复现、可审计的工作现场。

四、Mythos 复现实验与 Axios 事件：AI 安全的壁垒越来越像系统工程，而不是单一模型

来源：AISLE · OpenAI

AISLE 对 Anthropic Mythos 展示案例的复现实验，是今天最值得工程团队细看的安全文章之一。它的核心观点很有冲击力：AI cybersecurity capability 是 jagged 的，不会随模型大小、模型代际或价格平滑提升；真正的壁垒是系统，而不是单一模型。

AISLE 的实验方法不是重新做完整的端到端漏洞发现，而是把 Anthropic 公布的几个代表性漏洞案例拆出来，测试当相关代码路径已经被隔离后，小模型能不能恢复核心安全分析。结果很有意思：

8 个模型都识别出 Mythos 旗舰 FreeBSD NFS 漏洞；
其中一个只有 3.6B active parameters，成本约 0.11 美元 / 百万 token；
5.1B active 的开源模型恢复了 OpenBSD 27 年老 bug 的核心链路；
在某些基础安全推理任务上，小开源模型反而超过了多数 frontier 模型；
但在 patched code 的 specificity 上，模型又会出现明显误报。

这说明安全能力不是一个线性曲线。某些任务小模型已经足够，某些任务需要 frontier 模型，某些任务真正难的不是识别，而是 triage、复现、降低误报、写 patch、让 maintainer 接受。

这和 OpenAI 披露 Axios developer tool compromise 的事件放在一起看，更能说明问题。OpenAI 表示，Axios 作为第三方 developer library 在 2026 年 3 月 31 日被更广泛的软件供应链攻击波及；OpenAI 的 macOS app signing workflow 曾下载并执行恶意版本 Axios 1.14.1。该 workflow 访问过用于 ChatGPT Desktop、Codex、Codex-cli 和 Atlas 的证书与 notarization material。OpenAI 称没有证据显示用户数据、系统、IP 或软件被篡改，也认为签名证书大概率没有成功外泄，但仍按 compromised 处理，进行撤销和轮换。

这两个案例指向同一个结论：AI 安全的主要战场不是“模型能不能发现一个漏洞”，而是整个系统能否把风险闭环。

安全系统至少要覆盖五层：

发现：模型能不能找到可疑代码；
判断：能不能区分真漏洞和 false positive；
复现：能不能在真实环境里验证；
修复：能不能给出可接受 patch；
供应链：工具、依赖、CI、签名、凭证是否被保护。

Mythos 展示的是发现与 exploit construction 的上限；AISLE 提醒我们，便宜模型在局部任务上也可能很强；OpenAI 的 Axios 事件则提醒我们，再强的 AI 工具也可能被普通软件供应链攻击打穿外圈。

对 AgentOS 和所有开发者工具来说，这里有一个非常现实的产品要求：agent 不能被当作一个“更聪明的脚本执行器”。它运行的位置通常非常敏感：源码、环境变量、token、CI、SSH、浏览器登录态、本地文件系统。只要 agent 能帮你做事，它也可能在被污染时帮攻击者做事。

所以 agent runtime 的安全设计要比普通 SaaS 更严格：

插件和 MCP server 需要审计；
依赖要锁版本、验签、最小权限；
CI 中的 secrets 要分层暴露；
本地执行和远程执行要隔离；
输出产物要检查 source map、调试文件、测试数据和意外泄露；
高危操作要留痕和可回放。

AI 安全的终局不会是“买一个最强安全模型”。更可能的形态是：多个模型、多个静态/动态工具、多个沙箱、多个审计层，组成一个能把错误挡在外面的系统。

金句： 在 AI 安全里，模型负责产生怀疑，系统负责让怀疑变成证据、补丁和可被信任的流程。

本期结论

今天这几条新闻连起来看，会发现 AI 产业正在从“模型能力展示”进入更复杂的系统竞争阶段。

AI Job Loss Tracker 和 MIT 对就业数据的讨论说明，社会已经不满足于听宏大预言，而是要可追踪、可拆解、可治理的数据。Berkeley RDI 对 benchmark 的攻击说明，行业不能再把榜单成绩当作能力本身，必须看真实工作流。Cirrus Labs 加入 OpenAI 与 Colab 支持 MCP 说明，agent 竞争正在下沉到执行环境和基础设施。AISLE 与 OpenAI 的安全案例则提醒我们，真正可靠的 AI 系统必须覆盖模型之外的依赖、凭证、CI、签名和审计链路。

这四条线共同指向一个判断：

AI 的下一阶段，不是模型一个变量决定一切，而是测量体系、执行环境、安全边界和业务闭环一起决定谁能留下来。

对我们自己的产品矩阵也是一样：

写手不能只是“会写”，要能完成从热点、成稿、改写、配图到发布前质检的链路；
识川不能只是“会生图”，要能连接商品洞察、素材生产和转化测试；
Miolumi 不能只是“会陪聊”，要能处理长期关系、风险边界和真实用户反馈；
AgentOS 不能只是“会开终端”，要成为多模型、多环境、可审计的 agent 工作现场。

金句： AI 公司最早比的是模型，后来比的是产品，再往后比的是谁能把测量、执行、安全和商业闭环组织成一个稳定系统。

数据来源：AI Job Loss Tracker · MIT Technology Review · Berkeley RDI · Cirrus Labs · InfoQ · AISLE · OpenAI

本文基于公开资料整理，不构成投资建议。