Cetas 是跑在你自己机器上的编码 agent。你用自然语言说话，它读文件、改代码、搜仓库、执行命令，边做边把过程摊开给你看。它构建于 Posoco —— 一个面向 MoonBit 的 agent 框架。
它是单机设计。看板、会话、配置、凭据，全部落在你机器的一个 home 目录里；没有云同步，也没有共享会话。一个人用就是完整的。
为什么采用它
引入一个编码 agent，最先要验证的往往不是它多聪明，而是它干过的活你能不能查。下面四条，装完就能亲手验证。
干过的活查得到出处：把一句需求建成一张任务图，依赖没跑完的任务安静等着，跑完的停在验收门口等你点头，你看的是 diff 和测试证据，不是它的转述。记录落在本地，你的 agent 自己也查得到——半个月后问它“这段代码为什么存在”，它答得上来；这些任务和记录，就是交接文档。见Board。
让 agent 评审自己的改动，“只报告别修改”全靠口头嘱咐。子代理把这句话变成配置：工具面和权限档位写在它的定义文件里，看不见 write，跑不了 bash，父会话开 yolo 也越不了权。让它调研三个模块也是同一条路——三个子会话同时读，主窗口只收三份摘要。见子代理。
40 个文件里找 3 处引用，逐条读就是付 40 次的钱。换成让模型写一小段程序去循环、过滤，只把那 3 处带回对话——那些内容从头到尾没产生过，也就没产生过费用。程序跑在 Wasm 沙箱里，文件系统和网络都碰不到。见Bunraku。
人和 agent 读的是同一份文档：全站有 llms.txt 和 llms-full.txt，每个文档页带 .md 源文件。让另一个 agent 先读完这套文档再决定装不装，是受支持的使用方式。
基础能力也都齐备：权限有五档姿态，会话每轮落盘、/rewind 精确回退，全部状态在一个 home 目录，选模型之前先看见哪家有额度、哪个更划算。这些在特色功能与配置里各有其页，这里不再展开。
三种入口、两种终端实现
| 入口 | 适合什么 | 怎么装 |
|---|---|---|
| 终端 · JS（首选） | 日常交互、会话回退、JS 专属功能 | npm 的 cetas |
| 终端 · Native（第二选择） | 不需要 Node.js 的 Go/Bubble Tea 终端，功能范围有所不同 | Homebrew、Scoop 或发布文件 |
| 编辑器 | 在代码已经在的地方工作，走 ACP | cetas-acp |
| 自动化 | 一次调用一个任务，脚本或 CI | cetas-run |
这些入口不是分叉的 Agent 内核：它们组合同一个 Cetas/Posoco，但 UI 和宿主能力不同，JS 与 Native 终端不保证完全互换。详见入口（Surfaces）。
从安装与首次运行开始。
为什么是 Posoco
如果你在写 agent，或者正在挑一个 agent 框架，这一节是给你的；只想用 Cetas 干活，可以放心跳过。
它和常见框架的差异，落在四件可以验证的事上：
agent 循环的事件流是封闭枚举。内核新增一种事件，所有没跟上的分支立刻变成编译错误，指到具体的分支——升级时不用通读更新日志去猜行为，编译器会直接告诉你哪里断了。
工具调用被拒时，返回的是结构化原因：没被提供、owner 不允许、已被撤销、schema 不匹配、被钩子拒绝。写 UI 和 observer 的人拿到的是可以 match 的数据，不用拿正则去解析提示词。
每个能力登记时都带着 owner，可以被另一个扩展领走，收窄成“藏而不废”——从目录里退场，调用通道还在。目录、归属、收窄是同一份快照，没有第二处状态。
供应商是各自独立的扩展。没有一张统一 router 把各家压成同一个形状，每家的完整能力在自己的扩展包里实现，Cetas 的供应商清单就是这样一个个攒出来的。
这些话需要证据，证据是 Cetas 本身：三个传输方式不同的入口组合同一个内核，没有分叉的 agent 循环。Posoco 的破坏性升级附带一张显式的迁移映射表，该改什么、改成什么逐条写明，不靠读 diff 反推。第一条能成立的前提是 MoonBit——封闭枚举加穷尽检查，“编译器告诉你哪里断”靠的就是这个。
Posoco 提供协议和端口；Cetas 是在它上面扛过真实负载的那个实现。