今天最重要的信号，不是某个 Agent 又能完成一个更酷的 demo，而是 Agent 产品的竞争层正在迁移：

从「模型能不能做事」，转向「系统能不能保管工作状态」。

过去我们评估 Agent，常看它能不能写代码、改网页、生成 PPT、操作浏览器。但生产级 Agent 真正难的不是一次性执行，而是持续工作：文件在哪里？上下文来自哪里？技能如何复用？权限如何控制？变更如何追踪？结果如何评测？什么时候必须让人确认？

一句话判断：

Agent 产品真正要管理的是工作状态、能力资产和验证闭环，而不是单次生成结果。

信号 1：持久 Agent 文件系统成为新基础设施

来源： Guillermo Rauch / Vercel
关键词： Agent Filesystem / Durable State / Remote Sandbox

Vercel Sandbox Drives 进入 private beta。它的关键变化是：sandbox 的文件系统状态可以通过 drive 独立于计算生命周期保存、挂载和复用。

也就是说，Agent 不再只能在一次性容器里执行任务，而可以拥有一个可持续的工作空间。

这件事很重要。长期任务、跨天续跑、多人审查、代码库构建、依赖缓存、artifact 版本管理，都需要一个持久层。

没有持久 filesystem，Agent 只能做短任务；有了持久 drive，Agent 才有机会从「临时执行器」变成「长期工作者」。

小黑把任务、文件、上下文、版本和产物放进一个可持续工作空间。
持久 workspace 的价值，是让计算可以结束，但任务状态、文件和产物不会消失。

架构含义： compute sandbox、drive/storage、run ledger、artifact store 必须解耦。计算可以随时销毁，但工作状态不能随计算一起消失。

可构建产物： Agent Drive + Run Ledger + Artifact Version History。

风险： 持久化也会放大隐私、脏状态和错误继承风险。必须配套 TTL、scope、secret scrub、权限边界和状态清理机制。

下一步验证： 设计一个跨天任务：今天让 Agent 生成文件和中间产物，明天继续执行，并要求它解释「当前状态来自哪里、哪些内容可以信任、哪些需要重新确认」。

进一步阅读：

信号 2：Codex workflows 正在把 Agent 从 coding 扩到业务自动化

来源： OpenAI Developers / Codex
关键词： Workflow Library / App Connectors / Domain Skills

OpenAI Codex 的官方用例已经明显超出 coding agent：从 Slack 发起任务、保存可复用 workflow 为 skill、自动更新文档、review PR、处理复杂代码库、构建 iOS app 等。

这说明 Codex 的产品方向不是单纯「更会写代码」，而是成为一个跨工具的 workflow automation surface。

Coding 只是入口，真实价值在于连接用户已有的工作系统，并保留用户的风格、组织规则和验收标准。

Workflow 不只是一个 prompt，而应该包含输入、连接器、权限、执行边界、产物格式、人工确认点和验收标准。

小黑在一面工作流货架前，把输入、连接器、权限、确认点和验收标准整理成可复用卡片。
Workflow Gallery 不应该只是 prompt 收藏夹，而是一组可执行、可审计、可验收的任务规格。

产品含义： Agent 产品需要 Workflow Gallery。每个 workflow 不只是一个 prompt，而应该包含：输入、连接器、权限、执行边界、产物格式、人工确认点和验收标准。

架构含义： 需要 connector broker、domain skill、tool permission、audit log、human approval。否则跨 app 自动化很容易越权、误操作或生成不可追踪的结果。

可构建产物： Codex-style Workflow Gallery：每个 workflow 都有明确的输入、连接器、权限、产物和验收标准。

风险： 跨 app 自动化最危险的地方，不是失败，而是「看起来成功但做错了」。默认应该 human-in-the-loop，先从低风险 workflow 开始。

下一步验证： 优先 dogfood 两类低风险流程：

  1. inbox draft：只生成回复草稿，不自动发送；
  2. PR review：只生成审查意见，不自动 merge。

进一步阅读：

信号 3：Design Skill 正在变成 taste layer，而不是单纯页面生成

来源： OpenAI Skills / Figma MCP / 设计社区讨论
关键词： Taste Skill / DESIGN.md / Preview Annotation

AI 生成 UI 的瓶颈正在变化：过去是「能不能画出来」，现在是「能不能稳定符合品味、品牌、细节和实现约束」。

OpenAI Skills 里已经出现面向 Figma 到代码的结构化 skill，强调 design token、Figma MCP、组件边界和 visual fidelity。OpenAI 与 Figma 相关 workflow 也说明，设计 Agent 不只是把图变成代码，而是要在 canvas、code、preview、annotation 之间反复对齐。

这背后的本质是：设计能力正在从 prompt 变成 taste layer。

一个好的 design skill，不应该只是「生成一个好看的页面」，而应该把品牌审美、组件规范、字体、间距、动效、截图反馈和实现约束沉淀下来。

小黑用味觉筛子筛掉随机生成，把品牌、组件、间距和截图反馈沉淀成品味层。
Taste layer 的核心，是把审美、组件约束和截图反馈变成稳定资产，而不是每次重新抽奖。

产品含义： 应该提供 taste library、design rules、preview annotation、implementation fidelity checker。

架构含义： design skill、视觉参考、组件约束、截图 QA、DOM diff、人工批注要连起来。否则每次生成都像重新抽奖。

可构建产物： Design Skill Pack + Visual QA Runner + Taste Profile。

风险： Taste skill 很容易变成主观提示词，最后不可评测、不可复现。必须引入截图评测、组件规范和视觉 diff。

下一步验证： 拿同一个 Reader Mac App prompt，分别跑 Codex、Claude、Hermes，对比三件事：视觉一致性、实现保真度、修改后的细节损失。

进一步阅读：

信号 4：Claude data analytics 说明生产级 Agent 的核心是 eval + data foundation

来源： Anthropic / Claude Data Analytics
关键词： Data Agent / Evals / Context Drift

Anthropic 披露，内部约 95% 的 business analytics queries 已由 Claude 自动化完成，整体准确率约 95%。

但它真正有价值的地方不是这个数字，而是它指出了数据 Agent 的核心问题：不是 SQL 能力，而是上下文、指标口径、数据模型映射和验证机制。

数据 Agent 最容易制造「精确幻觉」：答案格式很好、语气很自信、SQL 也看起来合理，但它可能用了错误的表、错误的字段、过期的指标定义，或者误解了业务概念。

数据 Agent 的可靠性不是一次 prompt 调出来的，而是被持续评测和维护出来的。

小黑拿着放大镜检查数据表、指标字典、查询轨迹和评测样例。
数据 Agent 的难点不是会不会写 SQL，而是能不能绑定指标口径、上下文来源和失败样例。

产品含义： 数据 Agent 必须有 Metric Dictionary、Context Refresh、Eval Case Builder、引用链和结果置信度。

架构含义： Agent 输出不能只是最终答案，还要绑定 query/tool trace、数据字典版本、上下文来源和 eval 结果。

可构建产物： Data Agent Readiness Checklist + Metric Eval Suite。

风险： 没有真实历史错误样例，就很容易高估 Agent 的数据分析能力。

下一步验证： 构建 20 个真实业务指标问题，故意引入 schema drift、指标口径变化、字段重名、时间窗口差异，记录 Agent 的失败模式。

进一步阅读：

信号 5：AI Operator 的难点来自真实业务混乱，不是 demo 不够酷

来源： Kimi Work / SMB workflow 讨论 / AI Operator 方向观察
关键词： AI Operator / SMB Chaos / Docs-as-Runtime

Kimi Work 从 coding 场景扩展到 working 场景，是一个很明显的方向信号：Agent 正在从开发者工具进入普通知识工作者的桌面工作流。

但真实业务不是整洁的 demo。中小企业的工作流常常是混乱的：客户在微信里改需求，邮件里发新版 PDF，飞书里补一句确认，文件名不规范，历史版本混在一起，最后还期待团队「都知道」。

所以 AI Operator 的核心不是让 Agent 全自动接管业务，而是先把混乱工作流整理成可追踪、可确认、可更新的状态机。

小黑把微信、邮件、文档、聊天里的变更归并到操作台，生成确认项和下一步动作。
AI Operator 的第一步不是全自动，而是把多渠道混乱变成可确认、可追踪的状态机。

产品含义： 应该做 change ledger、context inbox、docs-as-runtime、operator console。先让 Agent 帮人归并、提醒、确认、生成下一步，而不是直接替人做不可逆动作。

架构含义： 需要事件归并、冲突检测、来源可信度、人工确认和任务状态账本。

可构建产物： AI Operator Console：聚合多渠道变更，生成确认项、风险提示和下一步动作。

风险： SMB 数据越混乱，自动化误操作风险越高。早期不要追求 full automation，应该优先做 assistive operator：协助、确认、记录、追踪。

下一步验证： 找一个真实客户流程，画出四张图：渠道图、状态图、异常图、人工确认点。只有这个流程图跑通，Agent 才值得进入自动化。

进一步阅读：

今日总判断

Agent OS 的核心不是聊天框，而是五个系统：

  1. 持久工作空间：保管文件、状态、版本和产物；
  2. Workflow Templates：把可重复工作沉淀成可执行流程；
  3. Skill Registry：把能力资产标准化、复用化、可安装；
  4. Context + Eval：把上下文、指标、验证和失败样例纳入系统；
  5. Operator Console：让人能看见、确认、回滚和审计 Agent 的动作。

应加强赌注： Agent Workspace + Skill Workshop + Data/Design Eval。

真正有价值的不是一次生成，而是把成功经验、文件状态、上下文来源和验收标准沉淀为系统资产。

应延后赌注： 完全自动化 SMB 工作流和开放 skill marketplace。

当前阶段更应该先做确认、审计、私有 registry 和人工可控。

下一步验证： 用一个真实工作流做端到端 prototype：

多渠道输入 → Agent 归并状态 → 生成产物 → 人工审查 → 形成 run ledger → 沉淀成 skill。

一句话收束：

Agent 的下半场，不是谁更会生成，而是谁更会保管工作状态。