今天的大多数 AI Agent，更适合被理解为"会话系统"。中心是一个 model，system prompt 规定行为，memory 延长上下文，MCP server 和各种 tool adapter 扩展能力边界。这套栈很有用，在很多产品里也完全正确。
但它对一个关键问题回答得还不够好：能力本身如何随时间演化？
当一个普通 agent 变得更好时，改进通常并不真正"长"在 agent 身上。有人重写 prompt，有人替换 tool，有人加 retry、cache 或 wrapper service，有人发布一个新的 package 版本。Agent 可以使用这些改进，但这个能力依然不是一个拥有自己 schema、执行边界、排名和生命周期的可移植单元。
Rotifer agent 从另一个前提出发。真正有意思的单位，不只是会话，而是 Gene。
大多数 agent 优化的是 interaction
这不是批评，而是设计取舍。
主流 agent 栈优化的是 conversation、orchestration 和 product integration。如果你需要一个 agent 在单个应用里搜索网页、调用 API、更新 ticket 或起草回复，标准做法通常已经足够好：
- 用 LLM 负责 reasoning
- 用 memory 负责上下文延续
- 用 MCP 这类接口负责 tool access
- 用 application code 决定有哪些能力可用
这样的系统足够灵活，上线也快，也很容易解释给团队听。
但它默认并不会给"能力"本身提供一个一等公民级别的生命周期。一个 tool 可以被调用，但它未必被包装成一个可移植、可度量、可与替代方案竞争、也可被其他 agent 低摩擦复用的逻辑单元。
MCP 解决的是接口问题，不是能力生命周期问题。
以 tool 为中心的设计，代价藏在后面
一旦 agent 超过 demo 阶段，三个摩擦会越来越明显。
第一，能力很难被客观比较。如果两个 tool 都能解决同一个问题，团队往往按熟悉程度、本地 benchmark 或历史惯性做选择。很少有一个会随着能力一起传播的共享 fitness 信号。
第二，能力很难被干净地迁移。一个有用的 function 往往和产生它的整套应用绑在一起：framework 假设、runtime 假设、vendor 假设，以及各种一次性 adapter。
第三，能力改进基本靠人工扩散。即便某个团队发现了更好的实现，传播方式通常仍然是 copy-paste、package 升级，或者写文档通知别人。架构本身没有内建的 selection loop。
这就是为什么很多 agent 在单次会话里看起来很强，但一旦放到长期能力系统里，就显得脆弱。
Rotifer 把能力单位从 tool 换成了 Gene
在 Rotifer 里，基本单位是 Gene：一个功能内聚、声明了 input/output schema、带有明确 fidelity、并且可以被独立评估的能力单元。
一个 Rotifer agent 也就不只是"带一组 tool 的 prompt"。它是围绕 genome 构建出来的运行实体，而 genome 是一组可执行、可组合的 Gene 集合。
这会直接改变系统结构：
| 维度 | 今天的大多数 AI Agent | Rotifer agent |
|---|---|---|
| 能力单位 | tool function、skill package、adapter | Gene |
| 组装方式 | app 层 glue code | Genome + composition algebra |
| 选择机制 | 人工指定 | Arena 排名和 fitness |
| 迁移方式 | 拷配置、装 package | 可复用的 Gene |
| 执行边界 | 由应用决定 | 由能力本身决定 |
| 可移植性 | 往往依赖特定 runtime | 面向 cross-binding execution 设计 |
Rotifer 还把组合关系显式化了。它不是把 orchestration 藏在应用代码里，而是公开提供 Seq、Par、Cond、Try、TryPool 这些组合算子。
这件事很重要，因为 workflow 不再只是某个 codebase 的偶然产物，而变成了能力模型的一部分。
Rotifer agent 不是 prompt wrapper，而是 genome 驱动的执行体
这才是最实际的差异。
一个普通 agent session 回答的是这样的问题： "给定这段 prompt 和这组 tools，这个 model 现在能做什么？"
一个 Rotifer agent 回答的是另一个问题： "给定这套 genome，这些可移植能力应该如何被选择、组合和执行？"
这听起来有点抽象，但看一眼 CLI 就很直观了。
下面这个例子先看 Arena，再按 domain 创建 agent，最后运行它：
rotifer arena list --domain search.web
rotifer agent create search-agent \
--domain search.web \
--top 2 \
--composition Try
rotifer agent run search-agent \
--input '{"query":"rotifer protocol"}' \
--verbose关键不只是"agent 跑起来了"，而是它面对的是一个显式的、可排名的、可组合的能力池。这个 agent 操作的是 genome，而不是一堆只在本地应用里成立的隐式 wiring。
演化需要 selection，不只是 installation
差异在这里开始变成结构性的。
在普通 agent 生态里，一个新能力通常通过"有人发布，另一个人安装"进入系统。核心机制是 distribution。
在 Rotifer 里，能力不仅可以被分发，还可以被 评估 和 排序。Gene 会在 Arena 中竞争，而它们的 fitness 会进入生态层的选择机制，影响系统更偏好哪一种能力。
这会改变升级路径。改进不再只是"我们又接入了一个新 tool"，它也可以意味着：
- 我们用更强的 Gene 替换了较弱的 Gene
- 我们把组合方式从
Seq改成了Par - 我们通过
Try增加了 fallback - 我们让多个候选能力按排名竞争，而不是冻结成一个手选方案
生态不再只是静态工具箱，而更像一个带有 selection pressure 的能力市场。
可移植性被内建到了能力层
普通 agent 和 Rotifer agent 的另一个大差异，在于 portability 到底放在哪一层处理。
在很多 agent 系统里，portability 主要是 application concern。你迁代码、重接依赖、再祈祷新环境和旧环境足够相似。
Rotifer 则把这个边界下推到了 capability layer。Gene 可以被编译为可移植 IR，通过不同 binding 执行；在暂时无法完整编译时，也可以先用 wrapped 方式接入。无论是哪种路径，能力的打包方式都不再是事后补丁。
这并不会神奇地消灭所有 integration 工作，但它做了一件更重要的事：它把执行约束更早、更正式地暴露在生命周期里。
对于长生命周期 agent，这是一种更好的底座。
这不意味着什么
Rotifer agent 并不意味着"在所有场景里都优于其他 agent"。
如果你的目标只是围绕单个 model 快速搭一个 product workflow，那么标准的 tool-calling agent 可能更简单，也完全够用。
Rotifer 解决的是另一类问题。它面向的是你开始在意这些事情的时刻：
- 能力是不是可复用单元
- 组合是不是显式表达，而不是隐藏 orchestration
- 选择是不是可度量，而不是临时拍板
- 能不能跨 execution environment 迁移
- 优化对象是不是整个生态的长期演化，而不只是一次对话
它也不是要替代 LLM、prompt 或 MCP。它做的是给这些东西提供一个更强的 capability substrate。
最清晰的心智模型
如果只记住一个区别，那就是这句：
大多数 AI Agent 优化的是会话，Rotifer agent 优化的是能力生命周期。
会话可以很聪明、很有用，也可以很自主。能力生命周期则可以是可移植、可组合、可演化的。Rotifer 真正关心的，是把后面这些属性做成一等公民。
所以，"普通 agent"和"Rotifer agent"的差别，本质上不是 UX 差别，而是它到底由什么构成，以及这套架构允许什么样的改进循环发生。