T3 Code 是什么：客户端操控另一台机器上的 Agent
T3 Code 底层设计：先记录意图，再执行 Agent 动作
沿着 RPC、事件日志、outbox 与 Provider 跟踪一次命令
T3 Code 底层设计：先记录意图，再执行 Agent 动作知识学习CN编辑简报更新 2026-10-04
你将学会
- 守住环境边界
- 跟踪已提交的意图
- 让 worker 执行效果
开始前需要
- 服务器环境上有一个可丢弃项目
- 一个已登录的支持 Provider
在连接重要仓库之前，把可丢弃试用转化为证据
先看结论
- 文件、Git 与 Provider 由服务器负责。
- 事件日志是持久状态的事实来源。
- 命令回执不表示 Agent 已完成。
守住环境边界
`packages/contracts/src/rpc.ts` 定义独立升级的客户端与环境之间的 RPC 契约。订阅只发送当前视图所需状态；客户端偏好留在客户端，项目与环境默认值归对应服务器管理。
手机或浏览器不应拿自己的文件系统或 Provider 凭据代替服务器的数据。共享连接运行时承担跨平台的领域与重连逻辑。
跟踪已提交的意图
v2 Orchestrator 只决定事件，不在决策阶段执行 Provider 或文件系统 I/O。`EventSink` 在同一数据库事务中提交事件、投影、命令回执及 outbox 效果，然后才向订阅者广播。
因此命令得到回执表示意图已持久接受，不表示 Agent 已结束任务。这样的顺序支持幂等重试，也避免界面把尚未执行的效果当成成功。
让 worker 执行效果
`EffectWorker` 在事务之后处理已记录的副作用，并把结果送回编排流程。Provider 回合结束与后续 checkpoint 或 diff 完成，是两个不同里程碑。
若 Provider 进程丢失，绑定它的效果不能直接在新会话上重放。恢复流程应先处理旧任务。本系列只审阅设计与源码，没有在真实服务器测量这些行为。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
找出 RPC 契约和环境所有权。
- 2
区分命令回执与效果完成。
- 3
分别观察 Provider 回合与 checkpoint 收尾。
可复制示例
text
客户端 RPC -> Orchestrator 决策 -> EventSink 事务
outbox -> EffectWorker -> Provider / 文件 -> 结果事件常见问题
RPC 成功回执意味着代码改完了吗？
不是。它确认意图已被接受，worker 与 Provider 的结果随后才出现。
为何不在事件事务里直接改文件？
文档设计把外部 I/O 留在事务外，先记录待执行效果。
资料来源
- T3 Code / docs/internals/overview.md来源核查 2026-10-04
- T3 Code / packages/contracts/src/rpc.ts来源核查 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/Orchestrator.ts来源核查 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/EventSink.ts来源核查 2026-10-04
- T3 Code / apps/server/src/orchestration-v2/EffectWorker.ts来源核查 2026-10-04