邓明瑞 / 纯粹 数据中台 × AI Agent

OpenAI 的 Dots 文档里有一条很容易漏掉：按下 Pause，只会停掉 Dot 当前的主任务。它已经委派出去的后台任务可能还在跑，未来的 Schedule 也不会自动取消。已经发出的消息更不会收回来。

这个细节比“常驻 Agent”四个字更能说明 Dots 是什么。它接手的不是一次对话，而是一项持续责任；责任下面会长出主任务、后台任务和计划任务。启动很简单，停干净反而要理解这三层状态。

Grok Bot 的发布页很会抓人：一支常驻 Agent 团队，各自有电脑，会互相发消息，还能 24 小时干活。看到这里，我脑子里冒出的却是一个很扫兴的问题：东西呢？

八个 Bot 在群聊里分工、复述进度，看起来很忙。页面没做出来、文件找不到、外部动作没人敢确认，这支“团队”仍然只是八个聊天窗口。Grok Bot 值得看的地方，是它把多 Agent 协作接到了云电脑、应用和 Routine；也正因为接了出去，所有权和权限问题躲不过去了。

Meta 的 Muse 发布稿里有一句话让我停下来多看了几遍：每个用户会得到一台专属云电脑，Agent 和数据都住在里面。这比“个人 AI”具体得多。聊天窗口关掉了，浏览器、文件和登录会话还在，Muse 可以接着干活。

麻烦也从这里开始。一段回答写错了，关掉就行；一台拿着登录会话、半夜仍在运行的电脑做错事，后果已经落到外部网站。我想看的不是 Muse 会不会写计划，而是这台电脑如何留住现场、谁准它往外发东西，以及出问题时能不能查清楚。

数据平台里做一个“能回答任务为什么失败”的 Agent 不难：接入日志、元数据和模型，常见错误能说得像模像样。真正困难的是用户继续说“那你帮我修一下并重跑”，系统还能保持对象正确、权限清楚、执行幂等，并证明数据结果已经恢复。

我认为数据平台 Agent 的终点不是更自然的问答，而是可验证执行。自然语言意图要经过对象解析、证据诊断、变更计划、权限决定、受控操作和结果验收，最终每一步都能回到真实系统核对。

技术博客做 GEO，最容易走偏的动作是批量加“最佳实践、权威专家、深度解析”这类词。页面看起来更像宣传稿，真正可被验证的事实反而变少。搜索引擎或生成式答案可以抽取句子，却无法判断作者到底解决过什么问题。

我理解的 GEO 不是一套独立于 SEO 的魔法标签，而是让机器和读者都能准确回答三件事：这篇文章解决什么问题，依据是什么，作者为什么有资格提出这个判断。先把事实和证据写清，再谈抓取与结构化表达。

长任务超过上下文窗口后，把前半段对话总结成几段文字再继续，是最直接的压缩方法。它也最容易丢掉关键东西：用户说“不要提交”，摘要只保留了“修改配置”；工具状态仍未知，却被写成“部署失败”；一个尚未回答的问题从列表中消失。

上下文压缩不是文学摘要。它要把后续执行所需的约束和状态，从大量过程文本迁移到更小、可验证的运行表示。哪些可以概括，哪些必须原样保留，应该由信息职责决定，而不是按 token 比例截取。

把一个任务拆给多个 Agent，吞吐量看起来会立刻提升。真正跑到共享仓库、文档或业务系统时，问题也随之出现：两个 Agent 同时改同一文件，研究 Agent 更新了结论，写作 Agent 还在引用旧证据，两个执行 Agent 重复提交同一工单。

多 Agent 首先是并发系统，其次才是角色设计。分工名称并不会自动提供隔离、一致性和幂等。共享状态必须有 owner、版本和合并语义，外部副作用必须回到单一的授权与提交边界。

模型接口返回 HTTP 200，页面也开始逐字输出，很多监控就把请求记为成功。用户最后却只得到半句话，或工具参数少了一个括号。对流式链路来说，200 证明的只是响应头成功返回，不证明业务事件完整，更不证明最终结果已经保存。

我更倾向用事件不变量验收 SSE：对任意一次 Run，无论供应商协议、网关转换、代理缓冲和客户端重连怎样变化，都有一组顺序、唯一性、组装与终态条件必须成立。违反条件就明确标失败或未知，不能靠 EOF 猜成功。