定义¶

按"Agent 在系统中扮演什么角色"做的 MECE 分类——三类彼此独立、共同穷尽：

起源：用户与 Gemini 在 RootSwarm.ai sideproject 战略推演中协同提出（详见 raw 文件）。用户先提"Creator vs Refiner"二分 → Gemini 补 Operator → 用户判断"应该锁定 2+3"——是推演协同的产物，不是单一来源观点。

为什么是 MECE¶

按"Agent 输出后世界发生了什么"做切分： - Creator：世界多了一个数字资产（代码 / 文档 / 图片 / 视频） - Refiner：世界没多东西，但混乱信息变成了结构化秩序 - Operator：世界状态发生不可逆变化（钱被花了 / 邮件发了 / 设备被控制了）

任何 agent 行为都属于这三类之一或多类组合。单纯"理解上下文不输出"不算 agent 行为（属于 LLM 内部认知）。

三类的物理机制¶

Creator = 熵增引擎¶

给极少信息（一句 Prompt：写贪吃蛇） → 通过生成模型补全海量细节 → 吐出几千行代码或几十秒视频。信息量从少到多。

容错高：代码错了可改 / 图片丑了重抽 / 文章烂了重写。商业本质卖"廉价的创造力与脑暴劳动力"。

Refiner = 熵减引擎¶

给海量混沌信息（100 篇财报 + 几万条零散记录）→ 通过推理与抽取压缩成 JSON / 表格 / 本体图谱。信息量从多到少。

容错极低：要的就是确定性。一处幻觉（虚构金额 / 错列实体）让整个输出价值归零。商业本质卖"秩序与确定性"，不是"无中生有"，是"沙里淘金"。

Operator = State Alteration¶

不输出代码 / 不输出表格——直接改变外部系统状态： - 在 Stripe 发起一笔退款 - 给合作方发一封具有法律效力的确认邮件 - 通过 Computer Use 点击"取消订阅" - 控制硬件（自动驾驶 / IoT 设备开关）

对"权限隔离"和"Human-in-the-loop"要求极高——一旦犯错，后果不可逆（真金白银 / 名誉损坏 / 物理伤害）。商业本质卖"替你去办事 / 走流程"，解决"我懒得办"。

Creator 的脆弱性：模型公司必吃赛道¶

Creator 强依赖基础模型智能——你做 Cursor 类产品本质是 GPT/Claude 的高级封装。这个赛道被模型公司主动收割： - Anthropic 的 Claude Code → Claude Cowork → Computer Use 路径 - OpenAI 的 Codex → VS Code 一键集成 - Google 的 Antigravity IDE - Amazon 的 Kiro AI IDE

当下一代旗舰模型（Claude 5 / GPT-5）发布——原生支持千万级 Token + 自带多文件项目生成 + 内置 Computer Use 能力——纯 Creator 类创业产品的护城河瞬间灰飞烟灭。这是 platform-layer-collapse 的核心动力。

结论：纯 Creator 类创业 = 在火山口建房子。要做也只能做"垂直领域 + 私有数据"加持的 Creator（如医疗影像生成、法律合同模板生成），靠领域专精对冲模型升级。

Refiner + Operator 的三道护城河¶

核心判断：Refiner+Operator 结合体（"提纯 + 执行"）是模型公司既吃不掉也不想吃的赛道。三道护城河：

1. Integration Moat（脏活累活的工程泥沼）¶

模型公司想做的是标准、通用 API。但现实世界的 Refiner 和 Operator 任务全是非标脏活： - Refiner：要接千奇百怪的只读接口、写极易崩溃的爬虫、处理一堆 PDF 格式 - Operator：要适配不同网站登录校验、应对反爬机制、处理表单变动

模型公司绝不会为了一个小众的退款页面专门写适配——这给中间层 agent 应用极大生存空间。

2. Liability Wall（法律责任墙）¶

模型公司极度害怕承担现实世界法律风险——OpenAI/Anthropic 自己的 agent 一旦帮用户发邮件骂人、替转账出错 → 天价集体诉讼。所以它们主动加 Safety Guardrails 限制自家 agent 的执行范围。

第三方 agent 应用通过"Agent 拟定草稿 + 人类一键确认"模式（Action Board），把责任还给用户，打通了大厂不愿打通的最后一公里。

3. Private State Machine（私有状态壁垒）¶

Refiner+Operator 强依赖动态变化的私有数据： - 你的银行流水 - 你的私有日历 - 你过去半年的邮件 - 客户公司内部的工单 / 群聊 / 会议纪要

这些上下文不属于大模型训练集——掌握了用户私有状态机，就拥有了绝对的用户粘性。这与 process-data-vs-output-data 判断同源。

与已有 wiki 的对应关系¶

三元论的贡献：把散落在多页的不同 agent 类型讨论用 MECE 轴贯通起来，给后续对话提供一个公共"原子词"。

与 decision-execution-decoupling 的关系¶

decision-execution-decoupling 讨论 agent 内部 Decision 与 Execution 解耦（LLM 还是代码生成 Decision）。三元论是更外层的分类：任何 agent 都有 Decision + Execution，但 agent 整体扮演的角色（Creator/Refiner/Operator）决定了它在系统中的位置。

举例： - Claude Code（Creator）的 Decision 由 LLM 生成，Execution 是写文件 - Palantir AIP（Refiner）的 Decision 部分由 Ontology 定义（强类型 Schema），Execution 是查询/聚合 - Stripe Chargeback Defender（Operator）的 Decision 由 Refiner 阶段产物驱动，Execution 是调 Stripe API

RootSwarm.ai 案例：2+3 锁定¶

RootSwarm.ai sideproject 在战略推演中明确锁定 Refiner + Operator 结合体：

监听 Stripe Webhook 新争议
   ↓
[Refiner 阶段] 并发 Refiner agents：
   Agent A: Shopify API 查 IP / 订单元数据
   Agent B: 17track 查物流轨迹
   Agent C: Zendesk 翻客服聊天记录
   ↓
Root 节点整合 → 强逻辑"举证 Timeline"（含 AVS / 物流 / 矛盾）
   ↓
[Human-in-the-loop] Slack: "胜率 95%，请批示"
   ↓
[Operator 阶段] 商家点击 → 调 Stripe API 提交申诉数据包

为什么不是 Creator：不写代码、不生成新内容 为什么是 Refiner：把混乱（邮件 / 网页 / API 数据）压成强结构化举证 Timeline 为什么是 Operator：最后一步真的发起 Stripe API 调用，改变现实状态（争议状态变为已申诉）

详见 raw/notes/rootswarm-strategy-brainstorm-2026-04-27.md 阶段 9-10。

对 sentino-agent Agent Art 的诊断¶

Operator 定义的延伸：内部数据 state alteration 也算（2026-04-29 修正）¶

本页"Operator = State Alteration"段最初列的例子（Stripe API / 发邮件 / Computer Use / 控制硬件）都是 外部 SaaS / 物理世界 state alteration，容易让人把 Operator 收窄成"调外部 API"。实际 Operator 的判据是"产生持久化的、用户/系统可消费的状态变化"，不限于外部 SaaS：

• 写到用户的日记空间（生成日记 = Operator）
• 写到 Memex 的长期记忆 store（生成/整理记忆 = Operator）
• 写到 Agent Art 的 agent_outputs/{agent_id}/latest（数据生产者持久化 = 轻量 Operator）
• 写到 notification_queue 触发下游消费（事件持久化 = Operator）

判据：输出后是否产生了一个用户/系统在对话之外可读、可继续消费的持久化变化。若是，就是 Operator；若只是把混沌信息收敛成一个临时结构供当前会话读，就是 Refiner。

Operator 的两个正交分类轴（2026-04-29 修正）¶

之前判断"Sentino Agent Art 主要是 Refiner，Operator 能力较弱"收得太窄。Operator 实际有两个正交分类轴：

轴一：改变什么 state（What） - 内部数据 state：写到平台 / 用户的持久化 store（如生成日记、写 Memex、写 latest） - 外部 SaaS state：调外部 API 改变第三方系统状态（如 Stripe 退款、发邮件、Computer Use）

轴二：触发-回执时序（When） - 同步 Operator：对话中由用户语音直接触发，立即执行 + 立即回执（"现在记一下我感冒了" → AI 调 Memex 写入 → 回复"好的"） - 异步 Operator：对话中由用户触发，但执行 out of band，完成后通过持久化通道（如 notification_queue）推回主 Agent 让下次对话能消费（"明天帮我预约医院" → "好的去办" → 后台执行 → 完成后下次对话主 Agent 主动告知） - 独立 Operator：与任何对话脱钩，由触发条件（时间 / 事件）自启动（每晚自动生成日记 / 周期性整理记忆 / 紧急事件检测推 notification_queue）

Sentino Arts 当前位置（按两轴诊断）¶

Sentino 把"主 Agent 可调度的能力单元"统一抽象为 Art（详见 sentino-agent "Arts 抽象"段），三种 Art 形态（Tool / Skill / Agent，最后这种早期称 "Standalone Agent"）都能承载 Operator——Operator 类型由"改变什么 state"+"触发-回执时序"两轴决定，与 Art 形态正交：

注意：Agent Art 形态有三种触发模式——时间触发 / 事件触发 / 主 Agent 按需调用——"独立"只是其中一种。Tool / Skill / Agent 三种形态都能被主 Agent 按需调用（同步/异步），Agent 额外支持时间/事件自启动（独立）。

修正后判断：Sentino Arts 不只是 Refiner，已经是覆盖三种触发-回执时序的内部数据 Operator。生成日记 / 写 Memex / 写 latest / 写 notification_queue 都是 Operator——只是改的是 Sentino 内部 state，且分别由 Art 三种形态承载。

主 Agent 通过 read_xx Tool 读 Agent Art 的 latest 输出仍然是 Refiner（消费侧把多源数据收敛成对话回应）；创建 Art 时用户 prompt + 配置仍然是 Creator 边缘（用户半 Creator，非核心模式）。

真正的 Operator 演进缺口¶

Operator 演进真正的缺口在轴一（改变什么 state）的右列外部 SaaS state alteration，不在轴二。无论同步 / 异步 / 独立——只要触达外部 SaaS：

1. Liability Wall 硬约束——客户文档陷阱、医疗合规、性健康内容审核等场景的责任归属问题（详见三元论页 Liability Wall 段）
2. 需要前置工程投入——权限隔离 / 沙箱 / Human-in-the-loop UI / 责任合同 / Action Board 模式（"AI 拟草稿 + 人类一键确认"）
3. 与 amphiflow-pattern 强匹配——可预测路径走 workflow 执行 + 异常路径走 agent 兜底
4. Manus 案叠加跨境监管不可逆（详见本页"Manus 案叠加"段）—— 客户 / 合作方 / 数据涉及国别成新前置评估维度

对 Sentino 的具体含义： - "AI 替我办事"演进不需要从零起步——内部数据 state 方向已覆盖三种时序，可直接做更多产品形态（自动日记、自动周报、自动整理记忆、跨对话事件推送）；三种 Art 形态在内部执行特征上分工自然（Tool 偏单步快速调用、Skill 偏组合多步、Agent 偏自判循环 + 时间/事件触发），但三者都能被主 Agent 调用且都能承载三种触发-回执时序 - 真正的护城河 + 真正的工程深水区是 外部 SaaS state alteration——前置 amphiflow + Liability Wall 责任归属设计 + Manus 案后跨境监管前置评估 - Arts 抽象是承载 Operator 演进的工程基座（统一调用接口 / 统一治理 / 统一配置），而不是 Operator 演进本身——演进重心在"改变什么 state"轴上的右移，不是在 Art 形态上的扩张 - 详见 sentino-agent "Arts 抽象" + "当前 scope 边界" 段对三种 Art 形态和三种时序的具体例子

三元论 + amphiflow-pattern 的协同¶

amphiflow（默认 workflow + agent 兜底）解决的是"决策怎么产生"——LLM vs 代码。三元论解决的是"agent 在系统中扮演什么角色"。两个维度正交可叠加：

Operator 类应用最适合 amphiflow 模式——因为 Operator 不可逆错误代价高，default workflow + agent 兜底 + Human-in-the-loop 三层保障是必然架构。

适用边界¶

• 不适合纯认知任务：如开放式对话、陪伴、情感支持等任务无明确"输出形态"，三元论分类失去意义
• 不适用 Conversational Companion / Personal Assistant 类：24/7 messaging 跨场景常驻 agent（Clawdbot / Moltbot 类）核心价值在对话过程本身（陪伴 / 情感连接 / 长期 messaging 关系）——不创造数字资产、不主要做信息收敛、Operator 性极弱（每条 IM 算 state alteration 太牵强）。三元论"按输出后世界发生什么"的切分维度对此失效。这类 agent 应该按对话特征维度评估（seal-architecture / voice-presence）。详见独立验证报告 2026-04-27-agent-trichotomy-validation 盲点段
• 可能存在多类型 agent：复杂应用是 Refiner+Operator（如 RootSwarm）或 Creator+Operator（如自动写邮件并发送）的组合，但每个原子 agent 角色仍是单类型
• 三元论是产品/商业分类，不是技术架构分类：同一套 agent runtime 可以承载三种类型（Claude Code Agent Loop 同时能写代码和调工具），分类的是 agent 实例所扮演的角色

与学术分类法的正交关系¶

2026-04-27 独立验证（2026-04-27-agent-trichotomy-validation）发现：学术界没有完全等同的 MECE 分类，已有分类全部按内部维度切分，与三元论是正交补充关系：

三元论的独特位置：占了"按输出后外部世界发生什么"切分轴。这条轴在产品/商业战略对话里特别有用（决定能不能避开模型公司重力场 / 决定护城河类型 / 决定法律责任结构），是已有分类没有覆盖的角度。

Plan-and-Execute 模式：Refiner+Operator 工程分离的行业实证¶

Google Agent Bake-Off（2025 年 Google 内部 4 个 agent 项目对比）给出了与三元论 2+3 战略完全同向的工程化判断：

"Reserve the LLM strictly for reasoning and intent extraction. Use rigid JSON validation schemas (like Pydantic) to capture the model's output variables. Once the variables pass strict validation, hand them off to a traditional, 100% deterministic Python function or SQL query to actually execute the calculation or the database write. Let the AI do the thinking, but let your traditional code do the doing."

翻译三元论术语： - "LLM strictly for reasoning and intent extraction" = Refiner 阶段 - "Pydantic JSON Schema 校验" = Refiner 输出强类型化（与 decision-execution-decoupling 同源） - "deterministic Python/SQL function for doing" = Operator 阶段走确定性代码

含义：三元论 2+3 战略不是单次 RootSwarm 推演的产物，是 Google 内部 4 个 agent 项目集体收敛的工程经验——这条独立来源支撑给三元论"避开 Creator + 锁定 Refiner+Operator"的产品战略加了行业级共识权重。

Multi-agent 系统典型分工也呈现 Refiner+Validator+Operator 三段式：

"One agent extracts data (Refiner) while another validates it (Refiner 子段) and a third routes exceptions (Operator)."

Walmart Wally + Self-Healing Inventory：Refiner+Operator 企业级实证¶

2026-04-27 WebSearch 核实的 Walmart 真实 agentic AI 部署给三元论 2+3 战略加了一个企业级垂直整合实证：

$55M 节省数字（Walmart Corporate 2025-07-17 公告原话："This technology has already saved Walmart more than $55 million"）—— 重点品类是 volatile perishables（易腐品），Mexico City + Coyol 易腐配送中心是具体场景。

三档 Refiner+Operator 案例对照¶

Wally + Self-Healing 与已有案例形成完整产品光谱：

含义：Refiner+Operator 赛道有完整产品光谱——三元论 2+3 战略不只是"中小客单价中间层路径"，从 Walmart 自建到独立 SaaS 全覆盖。Walmart 案例特别有价值的一点是它证明了"垂直整合大企业自建 Refiner+Operator agent" 是 ROI 可验证的（$55M 节省 + 节省"out-of-stock"问题）。

与 research-preview-pattern 的呼应¶

Walmart 实际推出4 个 super agents（Sparky 客服 / Marty 卖家广告 / Wally merchant / Associate Agent 员工）—— 与 Kat Wu 提出的 PM 三阶段路线图（单任务 → 多任务并行 → 50-几百并行）的"多任务并行"阶段对齐。Walmart 是企业内部 multi-agent 部署的头部实证之一。

Google Agent Platform：Creator + Refiner 平台典型实例（2026-04-22）¶

Google Gemini Enterprise Agent Platform（2026-04-22 Cloud Next 公布）是 Creator + Refiner 平台典型实例——但不直接做 Operator：

为什么 Google 不直接做 Operator？¶

完美印证三元论 Liability Wall + Integration Moat 判断：

1. Liability Wall：模型公司极度害怕承担现实世界法律风险——Google 把 Operator 留给 ServiceNow / Salesforce / SAP 这种企业系统供应商，因为它们已有客户合同 + 责任保险 + SLA 框架处理执行风险
2. Integration Moat：模型公司想做的是标准、通用 API（A2A 协议）——把适配千奇百怪企业系统的脏活留给合作伙伴

这与三元论"Creator 是模型公司必吃赛道，Refiner+Operator 是中间层生存空间"判断完全一致——Google 一次性把整个 Creator 类（Build 柱 18 组件中的 3 个）+ Refiner 类（Scale 柱大部分）内化进自己的全栈平台，但主动不做 Operator——证明这条边界不是中间层创业公司的一厢情愿，是模型公司主动让出的空间。

对中间层 Refiner+Operator 创业的含义¶

Devin / Manus 反例：Operator 不可逆判断的产品级证据¶

2026-04-27-agent-trichotomy-validation 用 15 个真实产品反向测试，Devin 和 Manus 两个反例精确印证三元论的"Operator 容错率不可逆 + Liability Wall 风险"判断：

这两个反例把三元论的"Operator 风险"判断从纯推演升级为产品级证据——这是三元论 2+3 战略中"Liability Wall + Human-in-the-loop"硬约束的真实验证。

Manus 案叠加：跨境监管不可逆是 Operator 风险的新维度（2026-04-29）¶

Manus 案（2026-04-27 NDRC 叫停 Meta ~$2B 收购 + 创始人禁出境）给 Manus 的"Operator 类不可逆错误真实发生"判断叠加了第二种不可逆——跨境监管不可逆：

对三元论的扩展含义：Operator 类应用面临的不只是产品级不可逆错误（Liability Wall），还可能面临政治 / 法律层的跨境监管不可逆——尤其当 Operator 公司：

• 业务 / 团队 / 数据与某个国家有深度关联
• 被外国巨头收购作为退出路径（默认 AI agent 退出叙事）
• 涉及"被定性为关键技术"的 agent 工程能力（Manus 落入"重要 IT + 关键技术"两个监管口径）

含义：三元论中"Operator 类法律责任问题"（详见"待观察"段）需要扩展到跨境监管层——不只是单一国家的产品责任 / Safety Guardrails，还包括跨国资产 / 控制权流动监管。这给 Operator 类创业公司新增第四道护城河（或者说第四道风险）：跨境合规 + 主体注册地选择 + 创始人国别身份风险（详见 singapore-washing 与 chinese-investment-security-review）。

对 Sentino Agent Art Operator 演进路径的影响：详见 sentino-agent 跨境政策风险段。Sentino 是日本注册公司，与 Manus 结构不同，但 Operator 类演进时仍需前置考虑客户 / 合作方 / 数据涉及的国别，避免类似的跨境监管不可逆风险。

2026-05-04 frontier 模型公司商业化承认 Refiner+Operator 赛道¶

Anthropic / OpenAI 2026-05-04 同日宣布 PE-anchored FDE JV 给三元论 2+3 战略加了一个结构性新证据——frontier 模型公司正式商业化承认 Refiner+Operator 类 mid-market 部署是"想吃但吃不下、需要外包给独立 JV"的赛道：

含义：

• 三元论判断的稳定性提升 1 个量级 —— 从原"中间层创业公司视角的判断 + Walmart / RootSwarm 等独立证据"升级到"frontier 模型公司用真金白银（$1.5B + $10B）+ JV 法律结构正式承认这个赛道"
• 但 JV 是模型公司主导的合资，不是独立中间层 —— 给独立 Refiner+Operator 创业公司的含义双向：
• 正向：模型公司不会自己做 Refiner+Operator → 独立创业空间结构性存在
• 反向：JV 在 PE-owned portco 子集（几千家 mid-market）的渠道护城河极强 → 独立创业要避开 PE 阵营客户群，找 PE 推不到的客户细分
• 三元论 2+3 战略的产品光谱完整化：
• 高端：Palantir（FDE 自营）
• 高端：Anthropic / OpenAI JV（FDE 外包给 PE 主导独立 JV）
• 中端：Walmart 自建（垂直整合大企业）
• 轻量：RootSwarm（动态 / 短期 / SMB）
• 中间层创业新空间：非 PE-owned mid-market + 长尾 SMB + 消费者市场

Liability Wall 的 JV 模式实现¶

JV 独立法律实体承担执行责任 = Liability Wall 的资本结构实现。这给 Refiner+Operator 创业公司一个可借鉴的护城河实现路径——不是只能用"Action Board + 用户一键确认"的产品级方案，还可以用"独立法律主体 + 责任合同"的资本级方案。

含义：Refiner+Operator 创业公司可以根据客户规模选择不同的 Liability Wall 实现 —— 不需要在产品级方案上死磕。

待观察¶

• 第三个独立证据点出现后是否需要扩展为四元论？例如Curator（精选/推荐型）—— TikTok 推荐 agent / Spotify 歌单 agent。当前直觉是 Curator 是 Refiner 的子类（"从全网收敛到 top 10"），不需独立
• Operator 类应用的法律责任框架在 2026 是否会成形？参考 work-experience-ownership 法律真空判断——Operator 比 Refiner 责任问题更严重，第一个判例可能改变整个赛道生态
• Creator 是否会因为模型升级速度变慢而重新有创业空间？目前判断是"短期内不会"，但模型 scaling laws 触顶的时点决定了答案

相关概念¶

• platform-layer-collapse — Creator 是模型公司必吃赛道，Refiner+Operator 才是中间层生存空间
• ai-agent-moats — Integration Moat / Liability Wall / Private State Machine 是 Refiner+Operator 的三道结构性护城河
• palantir-ontology — Palantir AIP 是企业级 Refiner 代表（重装甲），可与轻量 Refiner（如 RootSwarm）形成"静态 vs 动态"对照
• process-data-vs-output-data — 过程数据是 Refiner 的输入原料、Operator 的执行依据
• agent-tool-design — 工具设计哲学按三类 agent 有不同侧重（Creator 重生成质量 / Refiner 重 Schema 强类型 / Operator 重权限隔离）
• decision-execution-decoupling — 三元论是 agent 角色分类，DED 是 agent 内部架构原则——两个维度正交
• amphiflow-pattern — Operator 类应用最适合 amphiflow 模式（不可逆错误代价高 → 默认 workflow + agent 兜底必然）
• claude-agent-sdk — Claude Code SDK 主要承载 Creator 类应用
• ai-first-engineering — CREAO Coding Agent 是 Creator 类元工具
• sentino-agent — Sentino Agent Art 当前主要是 Refiner 形态，Operator 能力较弱，潜在演进方向
• google-agent-platform — Creator + Refiner 平台典型实例（不做 Operator，留给 ServiceNow / Salesforce / SAP 接 A2A）——印证三元论 Liability Wall + Integration Moat 判断
• manus-case-2026-04 — 2026-04 Manus 案给 Operator 风险叠加跨境监管不可逆维度（NDRC 叫停 + 创始人禁出境 + 强制 unwind 交易）
• singapore-washing — AI agent 公司退出叙事（被欧美巨头收购）在 Manus 案后被结构性重写
• chinese-investment-security-review — 中国侧 AI 跨境投资管制完整机制，Operator 类创业公司新增的政治风险维度
• anthropic-openai-pe-jv-2026-05 — 2026-05-04 frontier 模型公司商业化承认 Refiner+Operator 赛道是"想吃但吃不下、需要外包给独立 JV"
• forward-deployed-engineer — FDE 模式典型交付的是 Refiner + Operator 类 agent 部署
• pe-anchored-ai-distribution — JV 模式给 Refiner+Operator 创业公司划赛道：避开 PE 阵营客户群、找非 PE-owned mid-market / 长尾 SMB / 消费者市场
• ipo-valuation-dual-track — Liability Wall 的资本结构实现路径

完整研究链路：→ 2026-04-27-agent-trichotomy-validation（独立验证 + Conversational Companion 盲点 + Plan-and-Execute 行业实证 + Devin/Manus 反例）