技术

Thomas 的工作方式

A practical look at how Thomas turns requests into plans, approvals, commands, plugins, and results.

命令如何执行

执行模型

所有请求在真正运行前都要经过规划、策略闸门和审计跟踪。

覆盖情况

契约状态: 32 implemented / 21 declared 命令族总数: 53

最后验证: 2026/3/1

我们跟踪什么

  • 具有明确深度的命令族
  • 每个命令族的覆盖与证据状态
  • 执行产物的路由/路径可追溯性
执行流水线
pipeline
user request -> approval check -> plan generation -> tool run -> result check -> activity log -> response

命令族矩阵

命令族来源: 发布仓库

32 已实现 / 21 已声明

命令总数: 400

最后验证快照: 3/1/2026

当前显示 53 / 53 个命令族。

命令矩阵控制搜索、筛选与视图模式

/acp

已实现
深度 2命令数 2

/agent

已声明
深度 0命令数 0

/agents

已实现
深度 4命令数 4

/approvals

已实现
深度 10命令数 10

/browser

已实现
深度 45命令数 45

/channels

已实现
深度 31命令数 31

/chat

已声明
深度 0命令数 0

/clawbot

已实现
深度 2命令数 2

/codex

已实现
深度 4命令数 4

/companion

已实现
深度 8命令数 8

/completion

已声明
深度 0命令数 0

/config

已实现
深度 4命令数 4

/configure

已声明
深度 0命令数 0

/cron

已实现
深度 16命令数 16

/daemon

已实现
深度 7命令数 7

/dashboard

已声明
深度 0命令数 0

/devices

已实现
深度 11命令数 11

/directory

已实现
深度 9命令数 9

/dns

已实现
深度 2命令数 2

/docs

已声明
深度 0命令数 0

/doctor

已声明
深度 0命令数 0

/doppelganger

已实现
深度 6命令数 6

/gateway

已实现
深度 36命令数 36

/health

已声明
深度 0命令数 0

/hooks

已实现
深度 7命令数 7

/library

已实现
深度 6命令数 6

/live-browser-smoke

已声明
深度 0命令数 0

/logs

已声明
深度 0命令数 0

/memory

已实现
深度 10命令数 10

/message

已实现
深度 29命令数 29

/models

已实现
深度 12命令数 12

/node

已实现
深度 17命令数 17

/nodes

已实现
深度 24命令数 24

/onboard

已声明
深度 0命令数 0

/pairing

已实现
深度 9命令数 9

/plugins

已实现
深度 39命令数 39

/qr

已声明
深度 0命令数 0

/repl

已声明
深度 0命令数 0

/reset

已声明
深度 0命令数 0

/sandbox

已实现
深度 3命令数 3

/security

已实现
深度 8命令数 8

/serve

已声明
深度 0命令数 0

/sessions

已声明
深度 0命令数 0

/setup

已声明
深度 0命令数 0

/skills

已实现
深度 9命令数 9

/status

已声明
深度 0命令数 0

/system

已实现
深度 10命令数 10

/telegram

已实现
深度 1命令数 1

/tools

已声明
深度 0命令数 0

/tui

已声明
深度 0命令数 0

/uninstall

已声明
深度 0命令数 0

/update

已实现
深度 8命令数 8

/webhooks

已实现
深度 11命令数 11

完整性证据

Approval log example23 events processed - 214ms total
integrity-audit
{
  "requestId": "rq-2026-03-02-001",
  "timestamp": "2026-03-02T01:09:04Z",
  "route": "/v1/chat/completions",
  "policy": "approved",
  "commandFamily": "/status",
  "result": "ok",
  "elapsedMs": 214,
  "hooks": [
    "before-model",
    "before-tool",
    "after-tool",
    "after-response"
  ],
  "trace": [
    "/api-gateway",
    "/planner",
    "/hooks",
    "/tool",
    "/validation",
    "/activity-log"
  ],
  "logFile": "/var/log/thomas/activity.jsonl"
}
Execution JSON example6 steps with validation checks
integrity-execution-json
{
  "userPrompt": "List repository status",
  "plan": {
    "family": "status",
    "command": "status",
    "policyGate": "ok",
    "approvalState": "required"
  },
  "execution": {
    "output": {
      "totalSteps": 6,
      "exitCode": 0
    },
    "checks": {
      "schemaValidation": true,
      "policyGate": true,
      "commandRules": true
    }
  },
  "record": {
    "activityId": "rq-2026-03-02-001",
    "logPath": "/var/log/thomas/activity.jsonl"
  }
}
Request flowPlanning, execution, and result path
integrity-flow
user request -> approval check -> plan generation -> tool run -> result check -> activity log -> response
CLI examplesHTTP and CLI use the same guarded path
integrity-gateway-parity
thomas prompt "status"
thomas ask "List repository status"
thomas --help --json

Gateway 契约与 CLI 一致性

非流式请求示例
curl request
curl -X POST https://127.0.0.1:8787/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <local-token>" \
  -d '{\n  "model": "local-gpt",\n  "messages": [{"role": "user", "content": "List repository status"}],\n  "stream": false\n}'
流式事件模型
sse events
event: response.started
data: {"id":"evt-01","type":"response.started","request_id":"rq-2026-03-02-001"}

event: tool.delta
data: {"id":"evt-01","type":"tool.delta","tool":"status","payload":{"phase":"running"}}

event: response.final
data: {"id":"evt-01","type":"response.final","status":"ok","request_id":"rq-2026-03-02-001"}
非流式响应格式
response.json
{
  "id": "cmp-102",
  "status": "ok",
  "model": "local-gpt",
  "request_id": "rq-2026-03-02-001",
  "usage": {
    "prompt_tokens": 14,
    "completion_tokens": 32
  }
}
CLI 一致性检查
CLI commands
thomas prompt "status"
thomas ask "List repository status"
thomas --help --json

插件执行边界

Hook 执行架构
plugin architecture
client
  |-- parser + policy gate
  |-- command planner
  |-- execution runtime
  \-- activity log
      |-- before-model hooks
      |-- before-tool hooks
      |-- tool.exec hooks
      |-- after-tool hooks
      \-- after-response hooks
生命周期

安装包

校验 Manifest 与校验和

在注册表中激活

通过受保护路径执行

停用并移除运行时状态

卸载包

Manifest 示例
plugin-manifest.json
{
  "name": "thomas-plugin-guard",
  "version": "0.1.0",
  "entry": "dist/index.js",
  "permissions": ["filesystem", "network:thomas-control"],
  "hooks": [
    "before-model",
    "before-tool",
    "after-tool",
    "after-response"
  ]
}
Install -> validate -> activate -> execute
plugin lifecycle commands
thomas plugin install ./dist/thomas-plugin-guard.zip
thomas plugin validate thomas-plugin-guard
thomas plugin activate thomas-plugin-guard
thomas plugin run thomas-plugin-guard --diagnostic
thomas plugin deactivate thomas-plugin-guard
thomas plugin uninstall thomas-plugin-guard

接下来要做什么

  • 不打算做的事: 无限制的自主执行。
  • 不打算做的事: 在没有路由证据的情况下宣称全面 API 覆盖。
  • 不打算做的事: 没有策略闸门的隐式信任。

命令证据快照

已实现

命令族级别的覆盖元数据已经与源产物关联起来。

Gateway 契约覆盖

已实现

HTTP 契约和 CLI 调用共享同一套防护与验证表面。

插件生命周期回放

已声明

下一步是带可回放跟踪的完整安装与策略 hook 验证。