Cloudflare把AI流量拆分为搜索、代理和训练三类，网站可分别放行或屏蔽。9月15日起，新域名默认拦截广告页面上的代理与训练流量，但多用途爬虫也可能连带影响SEO。

Cloudflare 最近宣布重做 AI 流量管理逻辑，不再简单判断一个机器人“是不是 AI”，而是根据它抓取内容后的用途，将流量拆成搜索、AI 代理和模型训练三类。网站所有者可以分别放行或屏蔽三类流量，免费计划也能使用这些选项。

这次更新的关键不是增加了几个开关，而是 Cloudflare 承认，过去那个笼统的“屏蔽 AI 机器人”按钮已经不够用了。搜索引擎正在生成答案，AI 助手需要实时访问网页，训练爬虫又可能长期保存内容；三者都带有 AI 属性，但对网站流量、版权和商业模式的影响完全不同。

按照 Cloudflare 在官方博客公布的时间表，新的默认策略将于 2026 年 9 月 15 日生效。对于届时新接入 Cloudflare 的域名，系统将在展示广告的页面上默认屏蔽训练和 AI 代理流量，同时继续允许搜索流量。

AI 流量控制是什么

**AI 流量控制是按照自动化程序使用网页内容的目的，对其访问权限进行分类管理的机制。**它与传统机器人管理的区别在于，后者主要关心访问者是不是机器人、是否恶意；前者进一步追问它抓取内容是为了建立搜索索引、即时回答用户问题，还是训练未来的模型。

Cloudflare 此前提供的一键式“阻止 AI 机器人”托管预设，重点针对抓取训练数据的机器人。这种做法适合希望全面保护内容的出版商，却不适合仍然依赖搜索分发、又希望接入 AI 助手流量的网站。

新的三分类体系试图解决这组矛盾：

| AI 流量类别 | Cloudflare 对其用途的界定 | 典型访问方式 | 对网站的潜在价值 | 主要风险 | 9月15日新域名默认值 | |—|—|—|—|—|—| | 搜索 Search | 建立或更新搜索索引，并向用户提供搜索结果 | 周期性抓取页面、链接和元数据 | 带来搜索曝光与外部点击 | 搜索结果直接生成答案后，点击率可能下降 | 允许 | | AI 代理 AI Agent | 代表用户实时访问、理解或操作网页 | 围绕一次任务临时读取页面 | 可能带来高意图访问或完成交易 | 内容被直接摘要，用户不再进入原站 | 广告页面默认屏蔽 | | 训练 AI Training | 收集并保存内容，用于训练或改进模型 | 大规模、重复、批量抓取 | 对网站通常缺乏直接流量回报 | 内容被长期吸收，难以追踪后续使用 | 广告页面默认屏蔽 |

**搜索类爬虫是以建立搜索索引和展示搜索结果为主要目的的自动化程序。**传统 Web 生态长期依靠“允许抓取，换取流量”的契约运转，网站把页面交给 Google、Bing 等搜索服务，后者通过搜索结果把用户送回原站。

**AI 代理是代表具体用户即时获取或处理网页信息的自动化程序。**例如，用户要求助手比较三款产品，代理可能临时访问官网、读取参数并整理答案；它与训练爬虫最大的区别，是访问通常对应一个正在发生的用户任务，而不是为未来模型批量积累语料。

**训练爬虫是为了训练、微调或改进机器学习模型而收集网页内容的自动化程序。**它对内容网站最具争议，因为一次抓取可能让模型长期获得知识，却不保证署名、引用或后续访问。

真正需要警惕的是“多用途爬虫”

**多用途爬虫是同时承担搜索索引、AI 功能或模型训练等多个任务的同一机器人身份。**Cloudflare 将从 9 月 15 日起按照该爬虫的全部用途执行策略，并采用最严格的适用规则，而不是只看它访问当下声称要完成的任务。

这项规则比三分类开关更值得站长注意。Cloudflare 明确点名，Googlebot、Applebot 和 Bingbot 等机器人可能同时具有搜索与训练用途；如果网站选择允许搜索、阻止训练，最严格策略仍可能导致这些多用途爬虫被拦截。

换句话说，“禁止拿我的内容训练模型”不再必然是一个与 SEO 相互独立的开关。对于依赖 Google 或 Bing 收录的媒体、电商和工具网站，错误配置可能让搜索可见度一并受损。

| 配置情形 | 单用途搜索爬虫 | 单用途训练爬虫 | 同时用于搜索和训练的爬虫 | |—|—:|—:|—:| | 搜索允许、训练允许 | 放行 | 放行 | 放行 | | 搜索允许、训练阻止 | 放行 | 阻止 | 按最严格策略阻止 | | 搜索阻止、训练允许 | 阻止 | 放行 | 按最严格策略阻止 | | 搜索阻止、训练阻止 | 阻止 | 阻止 | 阻止 |

**Cloudflare 选择最严格策略，是在用访问损失换取用途透明度。**如果一个平台希望自己的搜索爬虫继续被放行，就需要更清楚地拆分搜索、生成式回答和训练行为，而不能让同一身份获得一揽子权限。

这个方向有合理性，但代价也很现实。Googlebot 这类爬虫过去相当于网站必须接待的“大客户”，Cloudflare 现在把选择权交回站长，同时也把误伤搜索流量的责任交给站长。对个人博客来说，这可能只是少几个索引页面；对依赖自然搜索获客的商业网站来说，可能直接影响收入。

robots.txt表达偏好，边缘网络负责执行

**robots.txt 是网站向爬虫声明抓取偏好的文本文件，但它本身通常不具备强制执行能力。**守规矩的机器人会读取并遵守，伪装身份或无视规则的抓取程序则可以直接绕过，因此不能把修改 robots.txt 等同于真正完成封禁。

Cloudflare 正在扩展 Content Signals，让启用托管 robots.txt 的客户表达更细的内容使用意愿。官方给出的信号包括：

• search=yes：允许内容用于搜索；
• ai-train=no：不允许内容用于 AI 训练；
• use=reference：允许将内容作为参考资料使用。

**use=reference 表示网站允许系统参考内容来回答问题，但不代表允许将内容纳入模型训练。**这试图在“完全禁止 AI 使用”和“任由内容进入训练集”之间增加一个中间选项，适用于愿意被引用、却不愿永久让渡训练权的创作者。

不过，Content Signals 仍然只是偏好声明，而不是新的互联网法律或通用授权协议。它能否发挥作用，最终取决于抓取方是否识别、接受并遵守这些字段；真正的访问阻断仍要依靠 Cloudflare 在边缘网络上的机器人识别和安全规则。

BotBase先解决“看不见谁在爬”

**BotBase 是 Cloudflare 建立的已知机器人与自动化代理目录。**Enterprise Bot Management 客户现在可以在控制台中检索已验证机器人，查看它们属于搜索、代理还是训练类别，并复制检测 ID，用于配置更具体的安全规则。

BotBase 当前首先解决的是可见性，而不是完全自动化的控制。Cloudflare 表示将在 2026 年晚些时候继续扩展 BotBase，把它变成管理站点已知自动化流量的直接控制中心。

| 能力 | 适用范围 | 当前状态 | 实际用途 | |—|—|—|—| | 搜索、代理、训练三分类 | 包括 Free 在内的所有计划 | 正在推出，9月15日切换新默认值 | 分别允许或屏蔽不同用途的流量 | | 多用途爬虫最严格策略 | 使用相关 AI 流量策略的客户 | 9月15日生效 | 防止同一爬虫以搜索身份兼做训练 | | BotBase 机器人目录 | Enterprise Bot Management | 目录与检索功能已上线 | 查询机器人分类、流量和检测 ID | | BotBase 直接控制中心 | Enterprise Bot Management | 计划于今年晚些时候扩展 | 集中管理已知自动化程序 | | Content Signals | 启用托管 robots.txt 的客户 | 扩展支持中 | 声明搜索、训练和参考使用偏好 |

**BotBase 的价值建立在 Cloudflare 的网络可见性之上。**根据 Cloudflare 的产品资料，其服务覆盖约 20% 的 Web 资产，机器人管理系统每天参考约 2470 亿条威胁信号，并结合机器学习、行为分析和指纹识别判断访问者身份。

这些数字说明 Cloudflare 比单个网站更容易观察爬虫的跨站行为，但并不意味着识别可以达到 100% 准确。公开身份、固定 User-Agent 和可验证 IP 的机器人相对容易分类，使用住宅代理、无头浏览器或频繁切换基础设施的抓取程序仍可能被识别为普通访客。

这不是封掉AI，而是重新谈分发条件

**Cloudflare 的核心判断是，过去三十年的“抓取换点击”契约已经失效。**生成式搜索可以在结果页直接回答问题，AI 助手也能把多个网站的内容压缩成一段结论，网站承担了创作和托管成本，却未必再获得访问量。

Cloudflare 在 AI Crawl Control 的产品材料中称，生成式 AI 爬虫可能为了带来一次推荐访问而抓取网页数千次。即使不讨论版权，这也是一笔不对称的资源账：服务器承担抓取负载，内容被转化为答案，但广告展示、订阅转化和品牌触达可能都没有发生。

**彻底封闭内容也不是大多数网站的最优解。**一个新品评测网站可能愿意被搜索引擎索引，也愿意让购物代理在用户询价时读取页面，却不愿历史文章被批量收集进训练集；一个文档站可能希望 AI 编程助手实时引用最新文档，因为这会增加开发者采用率，但仍然反对离线复制整个知识库。

三分类开关正好对应这些场景。它把原来的“允许所有机器人”或“屏蔽所有 AI”两极选择，变成更接近内容业务实际需求的权限矩阵。

网站现在应该做什么

**网站管理员应在 9 月 15 日之前完成一次 AI 流量与搜索依赖审计。**最重要的不是立即打开所有阻止选项，而是先弄清楚哪些爬虫正在访问、它们带来了多少真实用户，以及业务能承受多大的搜索收录波动。

建议重点检查以下事项：

1. **核对当前 AI 机器人预设。**已经使用旧版“阻止 AI 机器人”功能的网站，需要确认迁移到新分类后是否仍符合原意。
2. **区分搜索曝光与直接内容消费。**不要把所有来自 Google、Microsoft 或 Apple 的自动化流量视为同一种用途。
3. **单独评估多用途爬虫。**如果自然搜索是主要获客渠道，阻止训练前应先确认是否会连带阻断 Googlebot、BingBot 或 Applebot。
4. **观察广告页面策略。**Cloudflare 将新域名的默认阻断范围与展示广告的页面关联，但站长仍应在控制台核实页面识别和实际命中情况，避免只根据公告推测。
5. **把 robots.txt 当声明，不要当防火墙。**需要强制阻断时，应使用边缘规则和机器人管理能力。
6. **建立变更前后的基线。**至少记录抓取请求量、带宽消耗、搜索索引量、自然搜索点击和 AI 引荐访问，方便判断策略效果。

**免费开放三分类控制是这次更新最实用的部分。**过去精细机器人管理通常属于企业安全产品，而 Cloudflare 现在把最关键的用途开关下放给 Free 用户，意味着个人博客、开源文档站和小型媒体也能参与内容访问规则的制定。

我们的判断：方向正确，但默认值只是谈判筹码

**Cloudflare 这次更新的方向是正确的，因为“AI 机器人”已经不是一个有实际管理价值的单一类别。**搜索引擎、任务代理和训练系统对网站的价值交换完全不同，把它们塞进同一个黑名单既粗暴，也容易误伤。

这套方案最强的地方是执行层。robots.txt 只能表达愿望，Cloudflare 可以在请求到达源站前直接放行或阻断；对于缺乏安全团队的小网站，这比自行维护 IP 列表、User-Agent 规则和行为模型可靠得多。

这套方案最大的风险则是多用途爬虫。最严格策略会迫使大型平台公开拆分用途，却也可能让普通站长先承受 SEO 和收录损失。Cloudflare 把权力还给网站的同时，并没有替网站消除选择成本。

更长远看，搜索、引用、代理执行和训练可能还需要继续拆分。仅仅允许“参考”并不能回答署名位置、引用长度、缓存期限、商业使用和收益分配等问题，按抓取付费也仍未成为 Web 的通用标准。

**这次更新因此不是 AI 内容版权问题的终点，而是基础设施层开始拒绝默认无限抓取。**当占据可观 Web 流量入口的 Cloudflare 把用途分类、访问控制和内容信号放进同一套产品里，AI 公司以后要获得高质量内容，可能需要提供更清楚的身份、更单一的用途，以及更可验证的回报。

参考与延伸讨论

• Reddit：检索 Cloudflare AI traffic options 相关讨论——查看开发者和站长对三分类策略及搜索误伤风险的讨论。
• Reddit：检索 Content Signals 与 robots.txt 讨论——了解社区对 ai-train、search 和 use=reference 等声明的看法。

Anthropic 为 Claude 5 一代模型重新定义上下文工程：少堆规则和示例，改为设计接口、组织文件、按需加载信息。AI 应用开发的竞争焦点，正从提示词措辞转向上下文系统。

Anthropic 近日发布面向 Claude 5 一代模型的上下文工程指南，把 AI 应用开发的重点从“如何写出一句完美提示词”，转向“如何让模型在正确时间拿到正确的信息”。这不是换了一个更时髦的名词，而是智能体、Claude Code 与长任务应用进入生产环境后，开发方法必须发生的一次升级。

**上下文工程是对模型输入信息、工具、记忆与加载顺序进行系统设计的工程方法。**提示词只是其中一层；项目规则、代码结构、历史记录、检索结果、工具定义、执行状态、示例和验证反馈，都属于上下文。

Anthropic 这次释放出的核心信号很明确：Claude 5 一代模型不再需要开发者反复强调同一条规则，但更依赖清晰的接口、合理的信息结构和可控的披露时机。换句话说，模型变强以后，低水平的提示词技巧价值下降了，系统设计能力反而更重要。

提示词没有消失，但它不再是主角

**提示词工程是通过调整指令措辞、结构和示例，引导模型生成目标结果的方法。**这种方法适合单轮问答、内容改写和边界清晰的小任务，因为开发者可以一次性把大部分要求写进输入框。

**智能体任务的问题在于，真正影响结果的信息通常无法一次写完。**一个负责修复代码缺陷的 Claude Code 会接触仓库目录、依赖版本、测试日志、Git 历史和团队规范；一个客服智能体则要读取用户身份、订单状态、退款政策和过去的沟通记录。此时，继续优化某一句提示词，就像试图用一张便签管理整家公司。

提示词工程与上下文工程的差别，可以概括为下面这张表：

| 对比维度 | 提示词工程 | 上下文工程 | |—|—|—| | 核心对象 | 单条或少量指令 | 完整的信息供应系统 | | 主要问题 | 这句话该怎么写 | 模型此刻该看到什么 | | 信息组织 | 常见做法是集中堆入提示词 | 分层存储、按需检索、渐进披露 | | 适用任务 | 单轮生成、简单问答 | 编程智能体、研究任务、复杂工作流 | | 工具角色 | 工具说明通常是附属信息 | 工具名称、参数和返回值都是上下文接口 | | 记忆方式 | 依赖对话历史 | 短期状态、长期记忆与外部知识分层管理 | | 验证方式 | 人工查看最终输出 | 测试、检查器、评分器与重试闭环 | | 主要风险 | 指令表达不清 | 上下文污染、信息过期、权限越界、Token 浪费 |

**Claude 5 时代最需要放弃的想法，是把更多文字等同于更多控制。**上下文窗口再长，也不意味着所有信息都应该提前塞进去；无关内容会争夺模型注意力，过时文档会制造冲突，重复规则还可能让模型误判优先级。

第一条规则：把上下文当作接口，而不是作文

**高质量上下文首先要有明确的信息边界。**开发者应当把长期稳定的项目约束、当前任务目标、可调用工具、动态执行状态和输出要求拆开，而不是写成一篇层层补充的长提示词。

一个实用的上下文结构通常包含五层：

1. 系统约束层：身份、权限、安全边界和不可违反的规则；
2. 项目知识层：架构说明、目录约定、编码风格和业务术语；
3. 任务状态层：当前目标、已完成步骤、失败原因和待办事项；
4. 外部能力层：工具定义、检索入口、文件系统和执行环境；
5. 结果验证层：测试命令、验收条件、评分标准和失败后的处理方式。

**分层的价值在于每类信息拥有不同生命周期。**编码规范可能几个月才变化一次，测试日志却每次执行都会更新；如果两者被混在同一份长文档里，系统既难缓存，也难判断哪些内容已经过期。

第二条规则：渐进披露比一次性灌输更有效

**渐进披露是先向模型提供信息地图，再根据任务进展加载具体内容的上下文策略。**它是这轮 Claude 5 上下文工程规则中最值得开发者重视的关键词。

渐进披露并不等于让模型盲目探索，而是先给它足够的导航信息。例如，Claude Code 启动时只需要知道项目由前端、服务端和数据库迁移三部分组成；当任务只涉及登录页面时，再读取对应组件、设计规范和测试文件，不必同时加载支付模块的全部实现。

一个适合 AI 编程项目的文件结构可以是：

project/
├── CLAUDE.md             # 全局规则、常用命令与架构入口
├── docs/
│   ├── architecture.md   # 系统边界与模块关系
│   ├── conventions.md    # 编码、测试和提交规范
│   └── decisions/        # 关键架构决策记录
├── tasks/
│   ├── current.md        # 当前任务与验收条件
│   └── completed/        # 已完成任务摘要
├── examples/
│   ├── preferred/        # 推荐实现
│   └── anti-patterns/    # 明确禁止的实现
└── src/                  # 业务代码

**文件树本身就是一种低成本的上下文索引。**模型先看到文件名和简短说明，就能决定下一步读取什么；只有被选中的文档才进入高成本上下文，从而减少无关信息对推理的干扰。

开发者可以把这个过程理解为查地图。出发前需要知道城市、道路和目的地，但没有必要把沿途每家商店的菜单全部背下来。

第三条规则：示例要有代表性，而不是越多越好

**示例学习是通过输入目标任务的参考样本，让模型模仿其模式和约束的方法。**过去常见的做法是堆叠大量 few-shot 示例，希望用数量压住模型的不确定性；面对能力更强的模型，这种方法的边际收益正在下降。

**Claude 5 一代更适合少量、高区分度的示例。**一个正确示例负责说明理想路径，一个边界示例负责展示特殊情况，一个反例负责指出不能做什么，通常比十几个高度相似的样本更有信息密度。

示例还必须与规则保持一致。项目文档要求使用异步接口，但参考代码仍是同步实现，模型很可能同时吸收两套相互冲突的模式；这类上下文污染比缺少示例更危险，因为问题看起来像模型不稳定，根源却是输入系统自相矛盾。

第四条规则：工具定义也是产品接口

**工具调用是模型根据结构化描述选择外部能力并提交参数的过程。**模型不会像人类工程师一样自行理解一个模糊命名的内部服务，它看到的工具名称、参数描述、返回字段和错误信息，就是完整的操作界面。

**糟糕的工具设计无法靠系统提示词彻底补救。**如果同时存在 search、find 和 lookup 三个用途重叠的工具，模型就要额外猜测边界；如果工具返回几百行未经筛选的日志，真正有用的错误原因会被埋在噪声里。

更稳妥的工具设计应满足四个条件：

• 名称直接表达动作与对象，避免抽象缩写；
• 参数数量尽量少，并清楚标注必填项和允许范围；
• 返回值优先提供摘要、状态和下一步线索；
• 错误信息说明失败原因，以及模型是否应该重试。

**工具数量同样需要控制。**一次暴露几十个相似工具，表面上增加了能力，实际上增加了路由成本；更合理的做法是按任务阶段或角色加载工具组，让模型只看到当前可能使用的能力。

第五条规则：记忆必须分层，并允许遗忘

**智能体记忆是保存任务状态、用户偏好和历史经验，以供后续推理调用的机制。**记忆不是把全部对话永久追加到上下文，也不是把每次输出原样写进向量数据库。

一个生产级记忆系统至少应区分三类内容：

| 记忆层 | 保存内容 | 建议生命周期 | 加载方式 | |—|—|—|—| | 工作记忆 | 当前目标、临时变量、执行进度 | 单次任务 | 默认加载 | | 情节记忆 | 某次任务的决策、失败和结果 | 数天至数月 | 按事件检索 | | 语义记忆 | 稳定事实、用户偏好、组织知识 | 长期保存并定期更新 | 按相关性检索 |

**遗忘机制是上下文工程的一部分。**过期价格、旧版接口和已撤销的用户偏好如果持续进入上下文，会让模型稳定地产生错误；因此每条长期记忆最好具有来源、更新时间、可信度和失效条件。

第六条规则：上下文预算要按价值分配

**上下文预算是一次模型调用中可用于指令、知识、历史、工具结果和输出的 Token 配额。**窗口上限只是硬件条件，真正的工程问题是如何把预算分配给最有价值的信息。

假设某个应用为一次任务规划了 100,000 Token，这只是便于说明的工程示例，并非 Claude 5 的官方窗口参数。开发者可以将 10,000 Token 留给稳定规则，35,000 Token 分配给检索文档，20,000 Token 用于近期操作历史，15,000 Token 用于工具返回，并预留 20,000 Token 给模型推理与输出。

**预留输出空间能够避免任务在最后阶段被截断。**很多长任务并不是败在检索不足，而是前期加载了太多仓库内容，导致模型在生成补丁、测试说明或最终报告时没有足够余量。

上下文预算还应结合四个指标动态调整：

• 相关率：已加载内容中，真正被任务使用的信息占比；
• 命中率：完成任务所需关键信息被成功加载的比例；
• 新鲜度：上下文与当前代码、数据和政策的一致程度；
• 单位任务成本：完成一次合格任务消耗的总 Token 与工具调用次数。

第七条规则：验证闭环比重复强调更可靠

验证闭环是让模型执行任务、接受可观察反馈并根据结果继续修正的流程。“不要犯错”“务必确保代码可运行”都属于弱约束；单元测试、类型检查、构建结果和确定性的验收脚本才是强约束。

一个面向 Claude Code 的任务文件，可以使用下面这种结构：

# 当前任务
修复登录状态在页面刷新后丢失的问题。

## 允许修改
- src/auth/
- tests/auth/

## 禁止修改
- 数据库表结构
- 公共接口字段

## 验收条件
- 现有测试全部通过
- 新增刷新场景测试
- 不在浏览器持久化敏感令牌

## 完成后输出
- 根因
- 修改文件
- 测试结果
- 剩余风险

验收条件必须能够被执行或观察。“代码优雅”无法直接验证，“单个函数不超过既定复杂度阈值、类型检查通过、刷新后会话恢复测试通过”则可以进入自动化流程。

社区常用的 PRP 可以视为这套方法的具体实现。**PRP 是把产品需求、精选项目知识、实施步骤与验证条件组合成一份面向智能体的执行蓝图。**它比普通需求描述更接近一份可运行的任务协议，但 PRP 并不是 Anthropic 唯一指定的标准，团队完全可以使用 Issue 模板、设计文档或内部任务系统实现同样的分层结构。

一套可以直接落地的迁移流程

**现有 AI 应用不需要推倒重来，也能从提示词工程迁移到上下文工程。**实际改造可以分为七步：

1. 记录模型每次任务实际收到的全部信息，而不只检查 system prompt；
2. 删除重复、过期和相互冲突的规则；
3. 把稳定知识、动态状态和任务要求拆入不同存储层；
4. 为文档和工具增加简短、可检索的描述；
5. 先加载目录与摘要，再按需要加载正文；
6. 将主观要求改造成测试、检查器或结构化验收项；
7. 用失败案例建立回归集，持续评估上下文变化带来的影响。

**上下文版本必须与模型版本一起记录。**一次任务表现突然下降，原因可能来自模型更新，也可能来自检索排序变化、工具描述修改或某份文档过期；如果系统只记录最终提示词，团队几乎无法复现问题。

建议至少记录以下运行数据：模型名称、上下文模板版本、被加载文件、检索结果标识、工具调用序列、Token 使用量、总延迟、验证结果和人工评分。上下文工程最终会像传统软件工程一样，需要版本控制、测试集、监控和回滚，而不是依赖某位“提示词专家”的个人经验。

三个最常见的反模式

**第一个反模式是把整个知识库一次性塞给模型。**长窗口降低了信息装载门槛，却没有消除注意力竞争；内容越多，检索与排序越需要工程化。

**第二个反模式是把所有失败都归因于模型能力。**当模型反复使用旧接口时，应先检查旧文档是否仍在检索库中；当模型选择错误工具时，应先检查工具边界是否重叠，而不是立即追加一段更强硬的提示词。

**第三个反模式是把社区模板当成万能方案。**CLAUDE.md、INITIAL.md 和 PRP 都是有用的组织形式，但模板中的每一条规则都会消耗注意力；团队应保留真正影响交付质量的约束，而不是复制数百行与项目无关的“最佳实践”。

上下文工程也是安全工程

**上下文安全是防止不可信内容改变系统指令、泄露数据或诱导模型越权操作的防护体系。**当模型能够读取网页、邮件、代码注释和第三方文档时，这些内容既是知识来源，也可能携带提示注入指令。

开发者应明确区分系统规则、可信内部资料和外部不可信内容，并把权限控制放在模型之外。即使上下文中的网页要求模型上传本地配置，底层工具也应因为权限不足而拒绝执行；让模型“记得不要泄露”不能替代真正的访问控制。

Claude 5 时代，真正的壁垒是上下文系统

**Anthropic 的新规则并没有宣判提示词工程死亡，而是把它降级为上下文系统中的一个接口。**对简单任务，清晰提示词仍然有效；对需要数十步操作、多个工具和长期记忆的智能体，决定效果的已经是信息架构、检索策略、工具设计和验证闭环。

**Claude 5 一代模型越强，开发者越不该用冗长规则束缚它。**更好的方法是提供清楚的目标、可靠的环境、恰当的信息入口和可执行的反馈，让模型能够探索，但不能越权；能够犯错，但必须看见错误；能够读取大量信息，但只在需要时读取。

这也是上下文工程比提示词工程更难、同时更有价值的原因：前者不是文字游戏，而是一套真正的软件系统。

参考来源

• Context Engineering Guide：从上下文结构、记忆、检索、工具调用到安全与生产评估的中文开源指南，可作为延伸阅读。
• Anthropic 官方博客《The new rules of context engineering for Claude 5 generation models》：本文讨论的主要事件来源；受文末域名范围要求限制，此处不附站外链接。

Midjourney收购个性化星座应用Co-Star，交易已于今年春季完成。它买下的不只是占星产品，而是一套高频、长期、主动推送的个性化助手入口。

Midjourney开始争夺“每天打开”的AI入口

Midjourney在当地时间7月23日宣布收购个性化星座应用Co-Star，正式把业务边界从图像、视频生成扩展到面向普通用户的个性化服务。交易已于2026年春季完成，双方没有披露收购金额、支付方式及团队整合安排。

这不是一笔常规的模型或人才收购。Midjourney过去最鲜明的产品标签是“生成内容”：用户输入提示词，系统交付图片或视频；Co-Star提供的则是另一种关系——它根据用户出生信息和社交关系持续生成每日内容，并通过通知让用户反复回来。

**个性化助手是能够长期保存用户背景、理解稳定偏好，并据此主动提供建议或内容的AI产品。**与一次性回答问题的聊天机器人相比，它更接近一个持续运行的用户模型：不仅知道用户此刻问了什么，还试图知道“这个人是谁”“他过去关注什么”“今天应该对他说什么”。

这正是Midjourney目前缺少的能力。

据The Verge和TechCrunch在7月24日的报道，Co-Star是一款可以免费下载的星座应用，主要功能包括每日运势、个性化建议，以及用户与朋友之间的匹配度分析。Co-Star在产品说明中称，其内容结合了人类洞察、美国国家航空航天局NASA的天体数据和AI生成能力。

需要说清楚的是，NASA数据只能提供天体位置等天文学信息，并不构成对占星学有效性的科学背书。Co-Star真正有商业价值的部分，不是“星座是否准确”，而是它把结构化个人资料、关系网络、内容生成和每日推送组合成了一套成熟的用户留存机制。

Midjourney买的是用户关系，不是星座算法

Co-Star最值得Midjourney买下的资产，是一套已经被消费者验证过的个性化交互框架。出生日期、出生时间和出生地点可以形成相对稳定的用户档案，好友关系又为档案增加了社交维度，系统由此可以低成本地产出看似高度定制的内容。

这种产品机制与传统AI绘图存在明显差异。图像生成通常以任务为中心，用户有需求时才打开产品；星座应用以用户本人为中心，即使用户没有提出问题，产品也能根据日期和个人资料主动推送一条内容。

两者对用户行为的要求完全不同。

| 对比维度 | Midjourney传统生成产品 | Co-Star | 合并后的潜在形态 | |—|—|—|—| | 核心入口 | 提示词与创作任务 | 每日运势与关系匹配 | 基于个人状态的主动内容 | | 用户档案 | 风格偏好、历史作品 | 出生信息、好友关系、历史互动 | 长期身份、审美与关系上下文 | | 使用频率 | 有创作需求时使用 | 可每日打开 | 从低频创作转向日常陪伴 | | 主要模态 | 图像、视频 | 文本、通知、关系图谱 | 文本、图像、视频和通知 | | 内容触发方式 | 用户主动输入 | 系统按日期主动推送 | 用户请求与系统主动触发并存 | | 当前价格信息 | 采用订阅制，具体方案可能调整 | 基础应用免费下载 | 收购后方案尚未公布 | | 主要风险 | 版权、训练数据与内容真实性 | 隐私、心理暗示与伪科学争议 | 多模态说服力放大上述风险 |

Midjourney过去已经证明，它擅长把复杂模型包装成简单而有感染力的产品体验。早期借助Discord，Midjourney没有先建设一整套社交网络，而是直接把生成、展示、围观和模仿放进现成社区，这种产品选择显著降低了获客和教育成本。

Co-Star提供的是另一种现成入口。它不要求用户学习提示词，也不需要用户先产生明确的创作意图，只要用户愿意提供个人信息，产品就能不断制造新的交互理由。

因此，把这笔交易简单理解为“AI绘图公司开始做星座”会低估Midjourney的目的。更准确的判断是：Midjourney正在从想象力引擎转向个人叙事引擎，而星座只是最容易建立身份感和情绪反馈的产品外壳。

星座是个性化AI的低成本试验场

占星产品天然适合测试生成式AI，因为它允许内容保持一定模糊度，同时又要求表达具有强烈的个人指向。系统不必准确预测具体事件，只需要把日期、关系、情绪和通用人生议题组合成一句“像是在对我说”的话，就能形成主观上的相关性。

这种机制在心理学中常被联系到巴纳姆效应。巴纳姆效应是人们倾向于把模糊、普遍适用的描述视为对自己高度准确概括的心理现象。生成式AI让这类内容可以被更大规模、更细颗粒度地改写，并通过用户历史反馈持续调整语气。

Co-Star的优势不一定来自模型本身，而可能来自它知道应该在什么时间、以什么口吻，对哪一类用户说什么。对于个性化助手而言，这种“上下文编排能力”往往比单次生成质量更重要。

Midjourney则能补上视觉表达。未来如果双方进行深度产品整合，系统可以根据用户状态生成专属星盘、每日视觉卡片、关系故事、梦境图像或短视频，而不是只提供一段文字。视觉内容比纯文本更容易被分享，也更容易建立品牌辨识度。

一个典型场景可能是：用户早晨收到一张根据当天星象、个人审美偏好和近期情绪生成的视觉卡片；打开后看到针对工作或关系的短建议；系统再根据其点击、停留、分享和反馈调整下一次内容。整条链路不需要用户写提示词，却用到了生成模型、用户画像、推荐系统和多模态内容生产。

这比单纯增加一个“星座生成”按钮更有想象空间，也更危险。

从工具到助手，关键差别是长期记忆

长期记忆是AI系统跨会话保存用户信息，并在后续交互中调用这些信息的能力。它正在成为消费级AI产品争夺的核心，因为基础模型的回答质量逐渐接近后，产品能否记住用户、能否主动服务，将直接决定留存率和迁移成本。

当前主流个性化AI大致存在四条路线：通用助手利用聊天记录和记忆功能理解用户；角色产品通过固定人设建立情感关系；可穿戴设备依靠环境数据形成连续上下文；垂直应用则围绕健康、教育、理财或占星等特定场景积累结构化资料。

| 路线 | 个性化依据 | 优势 | 局限 | |—|—|—|—| | 通用聊天助手 | 对话历史、文件、日程与偏好 | 能力范围广，任务覆盖多 | 用户资料零散，主动服务容易打扰 | | AI角色与陪伴产品 | 人设、长期对话、情绪反馈 | 情感黏性强，使用频率高 | 依赖关系与安全边界争议较大 | | 可穿戴AI | 语音、位置、视觉与环境信息 | 上下文连续，触发自然 | 硬件成本和隐私压力高 | | 垂直个性化应用 | 健康、学习、财务或出生资料 | 数据结构清晰，产品目标明确 | 场景较窄，专业可靠性要求高 | | Midjourney＋Co-Star | 审美偏好、个人资料、关系与时间 | 视觉表达强，分享传播效率高 | 科学性、隐私和产品定位存在冲突 |

Co-Star属于最后两类之间的特殊产品。它拥有清晰、稳定的资料字段，又具备陪伴产品的叙事方式；它不必解决所有问题，只需持续输出用户愿意阅读和分享的内容。

Midjourney收购Co-Star，也意味着它选择了一条不同于通用聊天机器人的路线。它没有从邮箱、办公套件或搜索入口切入，而是从审美、身份和情绪切入，这与Midjourney创始人David Holz长期强调的“想象力”定位并不冲突。

这笔交易还没有证明产品协同

目前最重要的不确定性，是Midjourney和Co-Star尚未公布具体整合方案。外界还不知道Co-Star是否继续独立运营、原有团队如何安排、用户数据能否在两款产品间流动，也不知道Midjourney会不会把自己的图像和视频模型直接嵌入Co-Star。

交易金额未披露同样限制了判断。如果这是一笔规模较小的团队及产品收购，其重点可能是快速获得消费应用经验；如果金额较高，则说明Midjourney看中的可能不仅是团队，还包括Co-Star的品牌、用户规模、留存数据和社交关系资产。

Midjourney的执行能力也需要重新验证。模型公司擅长提升生成质量，不等于擅长经营一款每天向用户发送建议的消费应用。后者需要推送节奏、内容审核、用户生命周期管理、隐私合规和心理安全等完全不同的能力。

Co-Star与Midjourney的品牌调性也存在潜在冲突。Midjourney长期吸引设计师、艺术创作者和视觉从业者，而Co-Star更偏向生活方式、社交和情绪消费；二者用户可能重叠，但使用动机并不一致。

更现实的问题是，视觉生成能力未必能直接改善占星产品的核心体验。如果整合结果只是给每日运势加一张漂亮图片，这笔交易的战略价值会非常有限；只有当双方把用户记忆、主动触发、关系网络和多模态生成真正连接起来，Co-Star才可能成为Midjourney的新产品底座。

个性化越强，风险也越具体

出生信息是具有长期稳定性的个人数据，而不是一次性提示词。出生时间、出生地点、好友关系、互动记录和情绪反馈一旦被组合，能够描绘出相当细致的用户画像，即使单个字段看起来并不敏感。

因此，双方未来是否共享数据、以何种法律依据共享、用户能否拒绝画像、历史数据能否删除，都会成为收购后的关键问题。Midjourney不能默认Co-Star用户同意把原有数据用于训练视觉模型，也不能把“改善个性化体验”当作无限扩展数据用途的授权。

生成式内容的说服力也会放大占星建议的影响。纯文本运势通常被视为娱乐，但当系统加入逼真的视觉、熟悉的个人历史、好友关系和连续叙事后，用户可能更容易把生成结果理解为确定性判断。

产品必须明确区分娱乐内容与医疗、心理、财务和重大人生决策。尤其当用户表达抑郁、自伤、被控制或其他高风险状态时，系统不能继续用星象叙事替代专业帮助，更不能为了互动率强化宿命论表达。

“使用了NASA数据”也需要被准确解释。天文学数据可以提高星体位置计算的准确性，但无法证明由此推导出的性格和命运判断具有科学因果关系。产品若故意混淆两者，就会从娱乐体验滑向误导性权威包装。

生成式AI公司的下一战是“用户模型”

这笔收购释放出的行业信号，比Co-Star本身更重要。基础模型公司过去两年的竞争重点是参数、跑分、生成速度和多模态能力；下一阶段的竞争重点，则可能转向谁能建立更完整、持续更新且被用户授权的个人上下文。

所谓用户模型，是系统对个人身份、偏好、关系、目标和行为模式形成的动态表示。大模型决定产品理论上能做什么，用户模型决定产品知道应该为谁做、何时做以及用什么方式做。

Midjourney本来已经掌握大量审美偏好信号，包括用户生成过什么、选择放大哪张图、反复使用哪些风格，以及愿意分享哪些作品。Co-Star则能带来身份叙事、关系结构和每日触达机制，两类数据在产品层面具有互补性。

但互补性不代表可以无条件合并。真正可持续的个性化，需要用户清楚知道哪些数据正在被保存、如何影响输出，以及如何关闭、修改或删除这些记忆。缺少透明度的“懂你”，最终很容易变成无法解释的画像和操纵。

判断：方向合理，成败取决于是否做成新产品

Midjourney收购Co-Star是一个合理但高风险的扩张动作。合理之处在于，它没有继续收购另一家图像模型公司来堆叠同质化能力，而是直接补充日活入口、用户画像和主动推送机制；风险则在于，占星的争议性可能限制产品边界，并让隐私和安全问题提前爆发。

这笔交易最值得关注的不是Midjourney会不会推出“AI星座图”，而是它会不会借Co-Star建立一个长期认识用户的多模态助手。如果答案只是前者，产品新鲜感很快会消退；如果答案是后者，Midjourney就不再只是创作者需要时打开的生成工具，而可能成为每天主动出现的个人媒体。

生成式AI公司正在从争夺提示词，转向争夺用户的长期上下文。Midjourney选择用星座作为第一块跳板，看起来有些出人意料，但从高频、个性化和情绪价值三个指标看，它比再做一个聊天框更符合这家公司的产品气质。

截至2026年7月24日，交易金额、整合时间表和数据处理政策仍未公开。接下来真正需要观察的，是Co-Star是否保持独立、Midjourney的视觉与视频模型何时接入，以及双方会如何处理存量用户数据授权。

参考来源

• iThome：Meta未来AI模型及产品将采用Midjourney技术：用于补充Midjourney在图像生成之外扩大技术合作范围的行业背景。
• 知乎：福布斯Top 50 AI公司简析——Midjourney：用于了解Midjourney早期产品定位、商业模式和公司背景；其中历史信息需结合当前进展阅读。

Cognition以低位九位数美元估值收购聊天式AI助手Poke。交易指向编码Agent的新战场：模型能力之外，沟通方式、人格和长期协作体验正成为竞争壁垒。

Cognition买下的不是聊天框，而是一套交互方法

Cognition 在当地时间 7 月 24 日收购了聊天式 AI 助手 Poke，并计划将后者的对话风格与交互模型带入编码 Agent Devin。根据 TechCrunch 当天披露的信息，这笔交易对 Poke 的估值处于“低位九位数美元”区间，通常可理解为约 1 亿美元起步的数亿美元低端范围，但具体收购价格、现金与股权比例，以及团队整合方式均未公开。

这笔交易最值得注意的不是金额，而是 Cognition 买下了一家并不以代码能力见长的公司。Poke 的核心卖点，是让用户像给朋友发消息一样与 AI 相处；Devin 的核心任务，则是理解代码库、使用终端、执行测试并交付 Pull Request。两者看起来相隔很远，实际上分别对应 Agent 产品的两端：一端负责把事情做完，另一端负责让人愿意持续把事情交给它。

**编码 Agent 是能够自主规划并执行软件开发任务的 AI 系统。**它与传统代码补全工具的区别，不是一次生成更多代码，而是能连续完成读取仓库、修改文件、运行命令、检查测试结果、修复错误和汇报进度等多个步骤。Devin 从发布之初就试图扮演“AI 软件工程师”，Poke 则补上了这个角色长期以来相对薄弱的一环——如何像一名靠谱同事，而不是像一台等待提示词的远程机器。

“人格”正在从装饰变成产品能力

**AI 人格是模型在语气、主动性、反馈节奏、记忆方式和边界表达上呈现出的稳定交互特征。**这里的人格不是给机器人加几个表情，也不只是让回答更幽默，而是让用户能够预测它会怎样回应、什么时候追问、何时保持安静，以及遇到不确定性时会不会假装完成任务。

Poke 对 Cognition 的价值，很可能在于它已经围绕这种可预测性建立了一套产品方法。一个聊天式助手如果要让用户像联系朋友一样频繁使用，就必须处理消息长度、回复时机、上下文延续、主动提醒和语气一致性；一个编码 Agent 如果要在数小时甚至数天的任务中获得信任，也必须解决同样的问题。两者使用的工具不同，但用户面对的心理问题一致：我能不能放心把事情交给它？

交互质量对编码 Agent 尤其重要，因为软件开发任务天然充满歧义。用户说“把登录功能修一下”，背后可能涉及 OAuth 回调、Cookie 策略、移动端兼容、数据库迁移和回归测试。能力较弱的 Agent 会直接选一条路径开工，最后交付一个看似完整、实际偏题的补丁；协作能力更成熟的 Agent，则应该先确认影响范围，在关键决策点请求批准，并把技术风险翻译成用户可以快速判断的选项。

人格在这里承担的是“协作协议”的作用。一个总是说“没问题”的 Agent 可能显得友好，却会掩盖失败概率；一个每执行一步都请求确认的 Agent 更安全，却会把自动化退化成高延迟聊天；一个长时间沉默、最后丢出数千行改动的 Agent，则很难进入严肃团队的生产流程。真正有用的人格，必须同时控制亲和力、确定性表达和打断频率。

Devin需要的，正是“怎么说”这一层

Devin 当前面对的竞争已经不只是“谁能写代码”，而是“谁更像一个可以管理的工程协作者”。Claude Code、Cursor Agent、GitHub Copilot 的 Agent 能力，以及 OpenAI 的 Codex 类产品，都在把文件编辑、终端执行、代码检索和测试修复变成基础配置。当底层模型可以被多个产品接入，单纯依靠模型跑分形成的领先往往难以长期维持。

下面这张表更能说明 Poke 对 Devin 的潜在意义：

| 产品形态 | 典型代表 | 主要交互方式 | 用户承担的角色 | 优势 | 当前短板 | |—|—|—|—|—|—| | 代码补全 | GitHub Copilot 早期形态 | 编辑器内逐行建议 | 驾驶员 | 延迟低、控制感强 | 难以独立完成长任务 | | AI 原生编辑器 | Cursor Agent | 编辑器聊天、Diff 与终端 | 驾驶员兼审核者 | 上下文贴近代码，修改反馈快 | 需要用户持续在线参与 | | 终端型编码 Agent | Claude Code 等 | 命令行对话与任务执行 | 技术负责人 | 工具调用直接，适合资深开发者 | 非技术干系人参与门槛高 | | 异步软件工程 Agent | Devin | Web、Slack、GitHub、工单系统 | 任务委派者与验收者 | 能并行处理任务，适合团队流程 | 长任务中的沟通与信任成本高 | | 朋友式聊天助手 | Poke | 消息式对话 | 对话参与者 | 低门槛、连续性和人格感强 | 缺少复杂工程执行能力 | | 融合后的潜在形态 | Devin＋Poke | 消息委派、主动汇报、工程执行 | AI 工程经理 | 同时覆盖执行和关系维护 | 仍需解决权限、安全与可靠性 |

Poke 带来的第一项能力，可能是更自然的任务澄清。优秀的工程师不会拿到一句模糊需求就立刻提交代码，而是会先找出缺失的验收标准。聊天式产品积累的追问策略可以帮助 Devin 区分哪些信息必须立即确认，哪些假设可以先记录后执行，从而减少用户在长提示词里一次性写完所有要求的负担。

Poke 带来的第二项能力，可能是更合适的进度沟通。编码 Agent 的任务执行时间远长于普通聊天回答，用户真正需要的不是持续滚动的思维过程，而是几个可操作的状态：已经理解了什么、当前卡在哪里、是否需要人工决策、预计还要完成哪些步骤。把终端日志原样倾倒给用户不是透明，而是把信息整理工作重新推回给人类。

Poke 带来的第三项能力，可能是跨任务的关系连续性。Cognition 过去已经强调知识库、长期记忆和可复用“剧本”，让 Devin 记住仓库结构、测试命令与团队规范。Poke 式交互如果被真正整合，记忆对象还会扩展到沟通偏好：某位负责人希望高风险修改先给方案，某个团队要求每次数据库变更附带回滚步骤，某个项目只在测试全部通过后才发送通知。

这不是给Devin套一层聊天皮肤

简单地把 Poke 的语气移植给 Devin，不足以解释一笔低位九位数美元估值的交易。聊天式 AI 的价值只有进入任务规划器、记忆系统和通知机制，才会转化为编码 Agent 的竞争力；如果整合结果只是让 Devin 的回复更像朋友，收购就会沦为昂贵的文案升级。

真正的产品整合至少需要覆盖四层：

1. 意图层：从自然对话中识别任务、优先级、约束条件和验收标准。
2. 执行层：把对话中形成的共识映射为代码检索、文件修改、终端命令与测试流程。
3. 沟通层：根据风险和任务阶段决定主动汇报、追问或静默执行。
4. 记忆层：将稳定规则写入团队知识，而不是把每句话都永久保存。

这四层中最难的不是生成一句自然回复，而是决定何时开口。Agent 如果在代码格式化、依赖安装等低风险步骤频繁询问，会破坏异步工作的意义；但当它准备修改数据库模式、删除生产资源或变更鉴权逻辑时，不请求确认又不可接受。人格必须与权限系统绑定，否则“像朋友”反而可能让用户降低警惕。

这也是 Devin 与普通聊天机器人的根本差别。普通聊天出错，代价可能是一段错误信息；编码 Agent 出错，代价可能是不可编译的提交、供应链风险、数据损坏或线上事故。越自然的交互越容易制造信任，而越强的执行能力越要求系统主动限制这种信任。

编码Agent竞争进入体验层，但能力仍是底座

这笔收购释放出的行业信号，是编码 Agent 正在从功能竞赛进入协作体验竞赛。过去厂商重点展示的是能否解题、能否调用终端、能否在 SWE-bench 一类基准上修复真实仓库问题；现在更关键的问题变成了，用户能否同时管理 5 个、10 个甚至更多 Agent，而不被状态更新和失败重试淹没。

基准成绩仍然重要，但它无法完整衡量团队使用体验。SWE-bench 是以真实 GitHub Issue 和代码仓库评估模型修复软件问题能力的基准，它适合测量任务是否解决，却很难衡量 Agent 是否在正确节点请求帮助、是否清楚披露了未解决风险，以及它的汇报能否让工程师在 30 秒内决定合并或退回。

Poke 式交互可能让 Devin 更接近“工程经理界面”，而不只是“远程开发者界面”。未来用户未必需要盯着 Agent 的每一次文件修改，而是通过消息了解多个并行任务：支付模块正在等待测试环境，文档更新已经完成，性能优化发现了架构级问题，需要人类选择方案。此时聊天不再是执行入口之一，而会成为调度多个 Agent 的控制平面。

模型能力依然决定这套体验是否成立。一个不会正确修改代码的 Agent，再友好也只是善于解释失败；一个经常误判测试结果的 Agent，主动汇报越多只会制造更多噪音。Cognition 收购 Poke 并不意味着编码能力已经解决，而是说明头部公司开始判断：在模型继续进步的同时，交互设计已经值得通过并购提前补齐。

低位九位数估值，买的是时间和差异化

低位九位数美元估值显示，Cognition 对交互资产的定价并不低。需要强调的是，“交易对 Poke 的估值”不等于 Cognition 支付了同等规模的现金，也不能据此推断 Poke 的收入水平；并购可能包含股票、留任激励、业绩条件和其他安排，在条款披露前不宜把估值直接写成成交现金价。

Cognition 选择收购而不是内部复制，可能是因为聊天产品中的细节很难靠功能清单复刻。模型提示词、通知策略、用户研究、消息节奏和品牌语气看起来都不构成传统技术壁垒，但这些细节需要大量真实对话才能调到可用状态。对于需要快速扩大用户面的 Devin 来说，买下一支已经理解消费级 AI 交互的团队，比让工程 Agent 团队从头学习如何建立情感连续性更节省时间。

这笔交易也可能帮助 Devin 走出纯开发者市场。异步编码 Agent 的直接用户虽然是工程师，但任务发起者还可能包括产品经理、设计师、客户支持和运营人员。消息式交互能够把“修改代码”包装成更容易委派的工作流，让非开发岗位提交问题、补充上下文并查看结果，而工程师继续负责架构、权限和最终审核。

不过，拓宽用户面会同步放大错误需求进入生产流程的风险。产品经理一句“把退款限制放宽”，可能对应合规、财务和风控的多重约束；如果 Agent 只追求顺畅对话，就可能把组织内尚未达成共识的想法过早变成代码。融合后的 Devin 必须懂得识别权限边界，而不是把每个说得像需求的句子都当成待办事项。

最大风险：越像同事，越容易被过度信任

拟人化是 Poke 带给 Devin 的优势，也会成为整合后的主要风险。用户容易把稳定语气误认为稳定能力，把流畅解释误认为真实理解，还可能因为 Agent 表现得像熟悉团队的同事，而忽视其记忆过期、上下文缺失或工具调用失败。

企业客户更关心的另一项风险是对话数据与代码权限的合并。聊天助手通常接触个人安排、沟通偏好和零散信息，编码 Agent 则可能接触私有仓库、工单、日志、云环境和部署系统。当两类上下文进入同一个记忆层，Cognition 必须提供清晰的数据隔离、保留期限、权限审计与删除机制。

主动性同样需要明确边界。一个会主动发消息的生活助手通常只是提醒用户，一个会主动行动的编码 Agent 却可能创建分支、修改依赖或触发自动化流程。消息中的“你看着办”对人类同事已经足够含糊，对拥有工程权限的 Agent 更是危险指令。

因此，Poke 与 Devin 的融合是否成功，不应只看回复是否更自然，而应看三组可量化指标：澄清后返工率是否下降、人工介入次数是否减少、关键风险漏报率是否降低。如果自然语言交互增加了消息数量，却没有提高任务一次完成率，这套“人格”就没有形成实际产品价值。

判断：这是一次方向正确、执行难度很高的收购

Cognition 收购 Poke 的方向是正确的，因为编码 Agent 的下一阶段确实不只是继续堆模型和工具。随着多家产品都能读写仓库、运行测试和生成 Pull Request，用户最终会选择那个最容易委派、最少制造管理负担、失败时最诚实的 Agent。

这笔交易的真正考验，是 Cognition 能否把朋友式聊天转化为专业协作，而不是把 Devin 变得更会说话。工程团队需要的不是一个永远热情的 AI 同事，而是一个知道什么时候确认、什么时候执行、什么时候承认做不到的系统。

短期内，Poke 不会直接让 Devin 的代码正确率跃升，也不会解决长上下文、复杂调试和生产事故定位等硬问题。它更可能降低使用编码 Agent 的“管理税”：减少提示词工程、压缩状态阅读时间，并让多个并行任务变得可控。

长期来看，编码 Agent 与聊天式助手的边界会继续消失。聊天会成为委派和管理任务的界面，代码执行会成为聊天助手能够调用的专业能力，而人格则负责维持长期信任。Cognition 这次收购押注的，正是一个越来越明确的判断：当模型能力逐渐接近时，谁更懂得与人合作，谁才更有机会成为用户长期保留的那个 Agent。

参考来源与延伸阅读

• TechCrunch，2026 年 7 月 24 日报道：披露 Cognition 收购 Poke、交易估值口径及双方产品整合方向。受文末域名限制，此处不附站外链接。
• Model Context Protocol Specification：MCP 官方规范仓库，可用于理解编码 Agent 如何以标准化方式连接外部工具与数据源。
• SWE-bench：基于真实 GitHub Issue 评估模型与 Agent 软件工程能力的开源基准及工具仓库。

OpenAI 将 GPT-Live 语音模式接入 ChatGPT 桌面应用，用户可用一次对话启动、检查和调整 Chat、Work、Codex 中的多项后台任务。

ChatGPT 桌面端能听着干活了

OpenAI 在 7 月 24 日升级 ChatGPT 桌面应用，将 GPT-Live 语音模式接入 Chat、Work 和 Codex 三个板块。用户现在可以直接口述目标，在同一段对话中发起、检查和调整多项任务；当智能体在后台执行工作时，用户仍能继续交谈并追加要求。

这次更新的重点不是“语音输入终于更自然”，而是 OpenAI 开始把语音放到智能体任务调度层。过去对 ChatGPT 说话，主要是在替代键盘；现在说出的内容可以变成多个持续运行的工作流，语音由此从输入法升级成了桌面应用的控制界面。

GPT-Live 是 OpenAI 推出的全双工语音模型，可以在生成语音的同时继续接收和理解用户声音。 相比“用户说完、模型思考、模型回答”的回合制交互，全双工意味着 ChatGPT 不必等一方彻底结束才能处理下一步，用户也可以在回答过程中插话、纠正和改变方向。

一句话启动多个工作流

多线程任务在这里指的是多个智能体工作流并行或交错推进，而不是计算机处理器层面的线程。 用户可以在一段语音对话中交代多个目标，ChatGPT 则把目标拆分到聊天、办公和编程环境中执行，并持续汇报各自进度。

OpenAI 给出的典型场景是商务旅行准备。用户可以让 ChatGPT 同时检查日历中的时间冲突、扫描收件箱中的航班变更，并根据会议背景准备会议记录；在这些任务后台运行时，用户可以继续喝咖啡、整理行李，或者通过语音追加“把周二下午的客户会提前半小时”之类的新条件。

单一对话成为了多个任务的统一控制面板。 用户不再需要分别打开日历、邮箱、文档和代码窗口，也不必为每个任务创建一段孤立提示词，而是可以像向一名助理交代工作一样，在同一个上下文中持续补充优先级、截止时间和输出格式。

新版桌面应用目前围绕三个任务入口组织能力：

• Chat 是通用对话与信息处理空间。 它适合讨论需求、检索上下文、解释结果，以及对其他任务进行追问。
• Work 是面向办公交付物的智能体。 它可以利用获准访问的应用、文件、浏览器和业务上下文，制作报告、文档、演示文稿、电子表格及网站。
• Codex 是面向软件开发的智能体。 它负责理解代码库、拆解工程任务、修改代码、检查执行结果，并根据用户反馈继续迭代。

语音模式把三个入口串成了一条连续工作流。 例如，用户可以先在 Chat 中讨论一次产品发布，再让 Work 整理发布简报和演示文稿，随后要求 Codex 修复演示环境里的一个问题；整个过程中，用户不必反复复制背景资料，也不必在多个窗口里重新解释目标。

GPT-Live改变的是对话节奏

GPT-Live 与早期 ChatGPT Voice 的根本差别是语音处理链路从串联管线走向原生、持续的音频交互。 2024 年前后的初代方案需要先把语音转成文字，再由大语言模型生成文本答案，最后把文本合成为语音；三段模型依次运行，信息与延迟都会在链路中累积。

OpenAI 后来推出的 Advanced Voice Mode 把音频理解和生成整合到一个模型中，减少了模型切换造成的等待，也能感知部分语调、停顿和情绪信息。不过，这类系统仍然以离散回合为基本单位，本质上还是“你说一轮、我答一轮”。

GPT-Live 的全双工机制让“听”和“说”能够重叠发生。 这更接近人类会议中的交流方式：用户听到方向不对时可以立刻打断，模型也能根据一句话中途出现的修正更新后续回答，而不必先把已经计划好的整段内容播完。

| 语音方案 | 处理方式 | 交互单位 | 能否自然打断 | 适合场景 | |—|—|—|—|—| | 初代 ChatGPT Voice | 语音转文字、语言模型、文字转语音三模型串联 | 完整问答回合 | 能力有限，通常需等待阶段切换 | 语音问答、朗读、简单指令 | | Advanced Voice Mode | 单模型直接处理和生成音频 | 离散语音回合 | 支持打断，但仍有明显轮次 | 陪练、头脑风暴、实时讲解 | | GPT-Live | 全双工语音理解与生成 | 持续对话流 | 可边听边说、随时纠正 | 长流程任务调度、多智能体协作 |

OpenAI 尚未在本次公告中披露统一的毫秒级延迟数据。 因此，外界目前无法用“延迟从多少降到多少”来量化 GPT-Live 的提升，实际体验还会受到网络状况、设备拾音、工具调用耗时及后台任务复杂度影响。全双工解决的是交互机制，不代表所有任务都会立即完成。

真正有用的是“边聊边执行”

边聊边执行是这次更新最值得关注的产品能力。 传统语音助手通常在收到指令后完成一个短动作，例如设置提醒、查询天气或播放音乐；新版 ChatGPT 桌面端面对的则是持续数分钟甚至数小时的开放任务，其中包含信息搜集、计划制定、工具调用、结果检查和用户审批。

用户可以在后台任务运行时继续与 ChatGPT 交流，这意味着对话不再被一次工具调用锁死。假设 Codex 正在检查一个大型代码库，用户仍可让 Work 根据产品文档先准备发布说明；如果邮箱扫描发现航班取消，ChatGPT 也可以主动把这一变化带回当前语音会话，而不是等所有步骤结束后一次性报告。

这种交互方式更像项目经理与执行团队之间的站会。 用户负责给出目标、判断和优先级，ChatGPT 负责拆分任务、汇总上下文并推进执行；遇到权限、歧义或高风险动作时，系统再请求用户确认。它比逐条填写提示词更省操作，但也要求模型准确区分“讨论一个想法”和“授权执行一个动作”。

ChatGPT Work 在这套结构中承担了办公智能体的角色。根据 OpenAI 的产品说明，Work 能连接应用、文件、浏览器及经批准的业务上下文，并可利用超过 1,400 款插件获取资料；它还能在计划模式中先提出问题、生成执行方案，得到批准后再正式推进。

桌面应用是这套能力比网页聊天更合理的载体。 本地文件、当前窗口、浏览器标签页和开发环境都天然集中在桌面端，ChatGPT 可以在用户明确授权后获得更完整的任务上下文。对于需要同时处理代码、邮件、表格和会议资料的工作，桌面端也更适合展示多个并行任务的状态。

它还不是可以完全放手的AI员工

GPT-Live 提升了下达指令的效率，但没有自动消除智能体执行中的可靠性问题。 语音表达通常比文字更随意，代词、省略句和临时改口也更多；一旦这些模糊信息被直接转化为邮件发送、日程修改或代码变更，错误的成本会高于普通聊天中的一次答非所问。

权限边界会决定这项功能能否真正进入企业环境。日历、邮箱、Slack、客户管理系统和代码仓库包含大量敏感数据，组织需要知道 ChatGPT 访问了哪些信息、调用了什么工具、改变了哪些内容，以及谁批准了高风险步骤。

成熟的多任务语音智能体至少需要三层保护。 第一层是执行前展示计划，让用户确认目标和关键步骤；第二层是对发送邮件、修改生产代码、创建外部分享链接等动作设置明确审批；第三层是保留可审计的任务记录，使用户能够追溯并撤销变更。

GPT-Live 本身也面临语音模型特有的安全问题。OpenAI 在系统卡中重点讨论了自伤、精神病性症状与躁狂、对 AI 的情感依赖、暴力和性内容等风险；全双工和更拟人的声音可能增强陪伴感，也更容易让部分用户高估模型的理解能力和判断资格。

越像真人的交互越需要清楚展示机器边界。 GPT-Live 可以更自然地回应停顿和打断，但这不等于它拥有稳定的人类意图理解，更不等于它应该替代医疗、法律或财务专业人员作出高风险决定。

与竞品相比，OpenAI在抢桌面入口

这次更新的竞争焦点不是谁的语音最像真人，而是谁能把语音、上下文和执行工具连成闭环。 单独的语音合成质量已经很难构成长期壁垒，真正决定产品价值的是模型听懂需求后能否访问正确资料、调用正确工具，并交付可检查的成果。

| 产品能力 | 普通语音助手 | 通用语音聊天机器人 | GPT-Live桌面工作流 | |—|—|—|—| | 主要目标 | 执行单步设备指令 | 回答问题和陪伴对话 | 调度并推进复杂任务 | | 上下文范围 | 设备与少量账户数据 | 当前聊天与上传内容 | Chat、Work、Codex及获准连接的工具 | | 任务持续时间 | 通常为秒级 | 通常为单次会话 | 可在后台持续运行 | | 多任务能力 | 以逐条指令为主 | 可讨论多个问题 | 可从单一会话启动多个工作流 | | 用户角色 | 发出命令 | 提问与追问 | 设定目标、审批计划、调整优先级 |

OpenAI 的优势在于已经把通用对话、办公智能体和编程智能体放进同一个桌面产品。它的短板也同样明显：任务越多，状态管理越复杂；工具连接越广，授权和审计压力越大；语音越自然，用户越可能在未仔细检查的情况下批准模型建议。

这项更新更像工作方式的预告，而不是已经成熟的终点。 如果 ChatGPT 能稳定处理任务依赖、冲突和失败恢复，语音会成为比侧边栏更高效的智能体入口；如果它频繁听错对象、遗漏约束或在多个工作流之间混淆上下文，所谓多线程只会制造更多需要人工收拾的半成品。

价格与上线范围仍需继续观察

OpenAI 截至 7 月 24 日没有在本次公告中公布 GPT-Live 桌面集成的独立价格。 官方信息显示相关能力正在逐步推送，但不同套餐可用的模型额度、后台任务数量、语音时长和工具权限仍可能存在差异，用户应以客户端实际显示为准。

GPT-Live 同期也在 ChatGPT 的 iOS、Android 和网页端面向全球用户推出，而桌面应用的特殊价值在于进一步打通 Chat、Work 和 Codex。由于功能采用逐步发布方式，即使使用同一套餐，不同账号看到入口的时间也可能不同。

开发者和深度用户最应该观察的是四个指标。 这些指标比声音是否自然更能判断它能否用于正式工作：

1. 打断后的上下文修正率： 用户改口后，已经启动的任务能否同步更新约束。
2. 并行任务的隔离性： 邮件、文档和代码任务是否会错误共享不相关信息。
3. 审批机制的颗粒度： 用户能否只批准某一步，而不是一次性放开整个流程。
4. 失败后的恢复能力： 某个工具超时或权限不足时，其他任务能否继续，并给出清晰状态。

ChatGPT Voice 这次终于不只是“用嘴聊天”，而是开始“用嘴管理工作”。 GPT-Live 让对话更连续，Work 和 Codex 让对话能够落到具体交付物上，桌面应用则提供了连接本地环境的入口；三者组合起来，才构成 OpenAI 所说的“口述需求，快速推进多项任务”。

最终决定这项功能价值的不会是演示中那杯咖啡，而是用户回来后能否得到三份准确、可审查且没有越权的成果。就目前的产品方向看，它是 ChatGPT 从聊天工具走向通用桌面智能体的重要一步；但在可靠性、权限控制和可审计性得到真实工作场景验证之前，最合适的定位仍是“能干活的协作者”，而不是可以无人监督的 AI 员工。

参考来源

• IT之家：OpenAI ChatGPT 桌面应用上线语音模式 —— 介绍 GPT-Live 接入桌面应用，以及通过语音推进 Chat、Work、Codex 多项任务的更新信息。