Trustabl

Agent Reliability Analyzer — 发现并修复 AI Agent 可靠性缺陷

Agent Reliability Analyzer 是 Trustabl 推出的开源确定性扫描器，可在 AI Agent 代码投入生产前发现并修复其中的可靠性故障。找出可能导致 AI Agent 失败的问题，然后用一条命令修复。

针对 Agent 代码的确定性静态分析，覆盖 9 种 SDK 和 7 种语言。 完全在本机运行：无需云端扫描器、无需账户、无需上传代码，也无需大模型。

截至 2026 年 10 月的 Agent 可靠性覆盖范围：340 多条规则 · 9 种 SDK · 7 种语言 · 5 个范围

如果 Agent Reliability Analyzer 帮你避免了一次生产事故，请给仓库点个 ⭐——这能帮助其他团队发现它。

---

Trustabl 合作伙伴 — 从你已在使用的目录安装

_{一个 Agent 可靠性引擎，十种入口。}

MCP 注册表 · mcprush 从任何 MCP 感知客户端扫描	Claude 目录 Claude 内的技能、Agent 和 扫描器	npm · PyPI 由你的 AI SDK 或 Pydantic AI Agent 调用的工具
VS Code 在编辑器中编写时 查看发现的问题	Cursor 同样的扫描功能， 作为 MCP 服务接入	CLI Homebrew、Scoop、 Docker 或二进制文件
GitHub Actions 根据严重性阈值 拦截构建	GitLab CI/CD 在目录中发布的 组件	Bitbucket 官方管道，无需 安装步骤

_{以上所有方式都在你自己的机器上运行相同的确定性扫描。
请参阅生态系统集成，了解涵盖了哪些 Agent SDK。}

---

Trustabl 会扫描 Agent 仓库，找出导致 Agent 在生产环境中出问题的缺陷： 工具描述过于含糊，模型无法判断何时使用；缺少重试和超时处理；参数未定义类型；缺少防护措施；以及工具授权超出 Agent 所声称的功能范围。随后，它会直接在你的源代码中应用修复。

其他所有 Agent 扫描器都只会给你一份报告。Trustabl 会直接给你补丁。

可靠性应在部署前构建，而不是部署后观察。

扫描完全在你的机器上运行。 无云端扫描器、无需账户、不上传代码、不使用 LLM——采用确定性静态分析。

docker run --rm -v "$PWD:/repo" ghcr.io/trustabl/trustabl:latest scan /repo   # try it, nothing installed

brew install trustabl/tap/trustabl                                            # macOS / Linux
scoop bucket add trustabl https://github.com/trustabl/scoop-bucket             # Windows
scoop install trustabl

trustabl scan .                                                               # find issues (fully local)
trustabl scan . --format json > scan.json
trustabl enrich --input scan.json --repo . --diff --apply                     # preview, then fix

9 个 SDK · 7 种语言 · 支持人类可读、JSON 或 SARIF 2.1.0 输出 · 适用于 CI 的退出代码 · 也可作为本地 stdio MCP 服务运行（trustabl mcp）。

对 Claude Agent SDK、OpenAI Agents SDK、Google ADK 和 MCP 服务提供最深入的覆盖。也支持扫描 LangChain / LangGraph、CrewAI、AutoGen / AG2、 Pydantic AI 和 Vercel AI SDK——完整矩阵请参阅 COVERAGE.md。

扫描无需密钥，也无需联网。应用修复时使用你自己的 Anthropic、 OpenAI 或 Google 密钥。

Agent 可靠性扫描示例

以下是对一个仓库进行 Agent 可靠性扫描的真实输出，该仓库包含一个使用 Claude Agent SDK 的客户端、一个 MCP 服务、一个子 Agent 和两个技能：

$ trustabl scan .

Scan summary
  Languages:          typescript, javascript
  SDKs:               claude_agent_sdk
  Tool definitions:   2    (custom tools with function bodies)
  Agent tool grants:  14   (tool names the agent may call)
  MCP servers:        1    (createSdkMcpServer)
  Subagents:          1    (inbox-searcher)
  Skills:             2    (action-creator, listener-creator)
  Findings:           14
  Overall score:      66%

Surface readiness
  skill:action-creator          45%  (5 findings)
  skill:listener-creator        54%  (4 findings)
  agent:AIClient.queryStream    64%  (2 findings)
  subagent:inbox-searcher       79%  (1 finding)
  tool:search_inbox             98%  (1 finding)
  tool:read_emails             100%  (0 findings)

Findings
  inbox-searcher
    [CSDK-201]  HIGH  Subagent is granted Bash  (agent/.claude/agents/inbox-searcher.md:1-5)
        A subagent with shell access can run arbitrary commands if it is
        compromised or misdirected.
        fix: Remove `Bash` from the subagent's `tools:` list unless shell access
        is essential. Prefer specific tools (Read, Grep, Glob) for read-only roles.

以下三点值得注意：

• 分别为每个界面评分。 整个仓库的总分会掩盖问题； skill:action-creator 的得分为 45%，能告诉你应该先从哪里着手。
• 每个发现的问题都附有修复方案，而不只是指出问题—— trustabl enrich --apply 会将这些修复写入源代码。
• 退出代码就是 CI 的拦截条件。 如果没有问题达到中等严重级别，则返回 0； 如果有，则返回 1，这样流水线就能阻止有问题的 Agent 发布。

AI Agent 演示时表现出色，投入生产后却问题频出

大多数 Agent 可靠性问题并不罕见。反复出现的总是同几类缺口：

• Agent 持有 Shell 工具，却没有输入防护
• 工具发起 HTTP 调用时没有超时设置，导致整个运行过程卡住
• 工具参数没有类型定义，模型只能猜测，而且经常猜错
• 完全没有接入可观测性，导致前三类问题都无迹可寻
• 工具描述含糊不清，导致模型调用错误的工具——56% 的 MCP 工具描述未能清楚说明用途，97.1% 至少存在一项描述缺陷（Hasan 等人，《MCP Tool Descriptions Are Smelly!》，arXiv 2602.14878——涵盖 103 个服务上的 856 个工具）
• 子 Agent 的描述注明只读，却被授予 Bash 权限
• 技能会自动批准不受限制的 Shell 访问
• 没有重试处理，一次临时的 500 错误就会导致任务失败
• Agent 循环没有迭代次数上限，不断消耗令牌，直到被终止
• 用户控制的 URL 被传入 fetch——SSRF 风险，就出在你的 Agent 中

这些问题在 Agent 运行前，就都能从源代码中看出来。Trustabl 无需联网，也无需 LLM，几秒钟内就能发现并修复它们。

本文档接下来将说明 Trustabl 会分析什么 和 扫描如何工作，然后介绍构建和运行方式。完整的实现参考请见 ARCHITECTURE.md；SDK 覆盖范围一览矩阵请见 COVERAGE.md。

分析内容——五个范围的 Agent 可靠性

Agent Reliability Analyzer 不会把一个代码仓库视为一整块不可区分的数据。每条 Agent 可靠性规则都恰好归入五个范围之一，每个范围接收不同的类型化输入：

• tool — 对每个工具定义触发一次。输入：ToolDef（@function_tool / @tool / @claude_tool 函数、Claude TS tool(name, description, schema, handler) 工厂调用、FunctionTool(fn) ADK 封装、@server.tool MCP 注册，或直接调用 shell 的函数）及其解析后的文件。可检测缺少文档字符串、HTTP 调用未设置超时、参数未声明类型，或未经规范化的路径流入 open()。（WebSearchTool() 等托管工具属于 Agent 范围的边缘数据，会以 HostedToolDef 而非 ToolDef 捕获。）
• agent — 对每个 Agent 声明触发一次。输入：AgentDef——Python 的 Agent(...) / SandboxAgent(...) / AgentDefinition(...) 调用、Claude TS 类型化常量 AgentDefinition、options.agents 中内联的 Claude TS 子 Agent，或 Claude TS query(...) 主线程 Agent（QueryMainAgent）——以及捕获的每个构造函数关键字参数和已解析的工具、交接及护栏边缘。可检测配有 shell 工具却没有 input_guardrails 的 Agent、与可访问文件系统的工具搭配使用 tool_use_behavior="stop_on_first_tool" 的 Agent，或 allowedTools 不受限制的主线程 Agent。
• subagent — 对每个 Claude Code 子 Agent Markdown 声明触发一次。发现方式为混合模式：规范路径 .claude/agents/*.md（任意路径深度，兼容 monorepo）加上针对所有 Markdown 文件的 frontmatter 结构回退检查（要求存在 name 和 tools/model），可发现将子 Agent 放在 categories/*.md、plugins/<x>/agents/*.md 或类似布局下的扁平集合代码仓库。输入：从 frontmatter 解析出的 SubagentDef——name、description、tools[]（原样保留）+ ToolGrants[]（解析后的权限语法）、disallowedTools、model、permissionMode（包括 bypassPermissions）、mcpServers、skills、isolation、hasHooks。可检测到获准使用内置 Bash 工具、但描述为只读的子 Agent（CSDK-110）。仅存在子 Agent 就会使 claude_agent_sdk 计入 SDKsDetected，因此 Claude pack 会加载，且 CSDK-110 会在纯 Markdown 子 Agent 集合中触发。
• skill — 对每个 Claude Code 技能（SKILL.md，任意路径深度）触发一次。输入：从 frontmatter 解析出的 SkillDef——name、description、allowed-tools → ToolGrants[]、disable-model-invocation——以及正文事实（动态上下文执行命令、外部 URL、提示词注入标记）和捆绑文件清单。可检测会自动批准不受限制 Bash 的技能（CSKILL-001）、在模型看到动态上下文前执行会发起网络外传或读取机密的命令（CSKILL-003），或可由模型调用且授予了有副作用工具的技能（CSKILL-050）。技能采用 Markdown 编写，因此技能规则不带 language:；只要存在 SKILL.md，就会加载 claude_skill pack。
• repo — 每次扫描整个清单时触发一次。可检测项目级缺漏，例如存在 OpenAI Agents SDK，却未配置自定义 trace 处理器。

分析单位是 Agent，而不是代码仓库

一个代码仓库可以声明零个、一个或多个 Agent，涉及一个或多个 SDK。同一代码仓库中的两个 Agent，其安全状况可能截然不同——一个配置了输入/输出护栏，另一个则没有。因此，Agent 范围的发现项会归因于构造函数调用位置上的特定 Agent；若将其扁平化为单一的代码仓库级结论，就会丢失这项归因，且结论也会出错。发现阶段会为每个代码仓库构建一个小型图（工具、Agent、子 Agent 及它们之间的边），供 Agent 范围和子 Agent 范围的规则查询。

规则仅适用于一个 SDK 和一种语言

检测同一概念问题（例如缺少超时）的 Claude-SDK 规则和 OpenAI-Agents-SDK 规则是两条独立规则，各自包含针对特定 SDK 的说明和修复文本——不会跨 SDK 进行转换。 当仓库并列声明来自多个 SDK 的 Agent 时，每个 Agent 只会根据声明它的 SDK 所对应的规则进行检查。语言之间也是如此：language: python 规则不会对 TypeScript Agent 生效。

它如何推理——扫描流水线

Agent Reliability Analyzer（trustabl CLI）分四步进行扫描。每一步的输出都是下一步的类型化输入，各次运行之间不共享状态——早期步骤构建的清单让策略选择能够基于数据，而非静态配置。

二进制文件不包含任何内置规则。流水线运行前，Trustabl 会从单独的 git 仓库（agent-reliability-rules）解析检测规则——获取最新规则，在本地缓存仓库，并在网络不可用时回退到缓存。这使规则更新与二进制版本发布相互独立：无需重新构建扫描器即可添加或更改规则。解析出的规则提交会记录在结果中，并纳入 ScanID，因此扫描结果会如实标明是由哪些规则生成的。如果无法获取规则且没有缓存，扫描会以 2 退出，并提示你运行 trustabl rules pull——Trustabl 绝不会在没有规则的情况下运行。

flowchart LR
    target[("Agent repo<br/>(local path or GitHub URL)")]
    recon["Recon<br/>files · SDK deps"]
    inv["Inventory<br/>Python + TS AST:<br/>tools · agents ·<br/>subagents · MCP servers"]
    pol["Policy selection<br/>load rules per<br/>detected SDK ·<br/>META findings"]
    ana["Analysis<br/>tool · agent · subagent ·<br/>repo detectors"]
    score["Scoring<br/>per-surface score ·<br/>overall readiness"]
    out[("ScanResult<br/>findings · scores<br/>(human / JSON / SARIF)")]

    target --> recon --> inv --> pol --> ana --> score --> out

1. Recon（初步探查） — 遍历仓库，以低成本回答“这里有什么”，而不解析任何源语言：存在的语言（按扩展名统计）、清单中声明的 SDK 依赖项（在 pyproject.toml / requirements.txt / Pipfile / poetry.lock / package.json 中查找 claude-agent-sdk / @anthropic-ai/claude-agent-sdk / openai-agents / @openai/agents / google-adk / @google/adk）、文件清单，以及发现的 Agent 组件（MCP 配置、钩子脚本、CLAUDE.md 和 AGENTS.md 指引文档、任意深度的 .claude/agents/*.md 子 Agent、SKILL.md 技能、.claude/commands/*.md 和 <plugin-root>/commands/*.md 中的斜杠命令、.claude-plugin/{plugin,marketplace}.json 清单、沙箱策略，以及仓库根目录下的 .github/workflows/*.yml GitHub Actions 工作流。此步骤不会进行 tree-sitter 解析——它会决定是否值得尝试耗费资源的 AST 处理。
2. Inventory（清单构建） — 对 Recon 确认的每种语言进行 AST 处理，并提取类型化清单：包含配置和正文信息的 ToolDefs、捕获所有 kwargs 的 AgentDefs、从 Markdown 和 JSON frontmatter 解析出的 SubagentDefs/SkillDefs / SlashCommandDefs/PluginManifests、MCPServerDefs、护栏、会话，以及 Agent 与其引用的工具/护栏之间解析出的边。检测器读取这些结构体中的字段——绝不会重新解析原始源代码。
3. 策略选择 — 仅加载代码中实际观察到的 SDK 对应规则包。如果代码中出现某 SDK，但没有随附的规则包，就会生成一条 META-001 信息类发现（“Trustabl 目前不会审计此 SDK”）——对未知 SDK 保持沉默是不正确的。如果某依赖项已声明，但从未在代码中使用，则会生成另一条不同的信息类发现，指出这种不一致。
4. 分析 — 针对清单运行所选的范围感知型检测器。发现结果会标明触发时所在的范围，并归因到正确位置：工具文件/行、Agent 调用点、子 Agent Markdown 文件或清单。

按此设计分阶段处理，会带来以下三项特性：

• 性能。 不含 Python 的仓库会跳过 Python AST 处理；只有 Claude TS 代码的仓库会跳过 Python AST 处理以及 OpenAI 策略加载。
• 覆盖情况如实。 “尚未审计的 SDK”信息类发现，比对 Trustabl 不熟悉的 SDK 给出零发现的健康报告更明确。META-004 发现还能进一步区分“已审计且无问题”和“无法审计——发现阶段未提取到任何规则目标”。
• 确定性是一项契约。 相同输入 → 相同 ScanID，报告在不同运行之间保持字节级稳定（发现结果按 (RuleID, FilePath, Line) 排序，清单切片以确定性顺序排序）。CI 使用方可以对比扫描结果，而不会出现无谓变动。

完整图示及每个步骤的类型化输入，请参阅 ARCHITECTURE.md § 2。

当前已接入的内容

工具/Agent AST 发现功能已接入：

• Python — Claude Agent SDK（装饰器）、OpenAI Agents SDK、Google ADK、LangChain / LangGraph、CrewAI、AutoGen / AG2 和 Pydantic AI。 发现功能会提取工具定义、Agent 构造函数、托管工具、MCP 服务、 防护机制和会话。OpenAI / ADK / CrewAI / Pydantic AI 共有的裸 Agent(...) 构造函数会按 SDK 的导入进行门控，因此这些类不会 交叉匹配；共有的 @tool 装饰器则会根据其导入绑定路由至所属 SDK。
• TypeScript — Claude Agent SDK（tool() 工厂、query() 主线程 QueryMainAgent、内联于 query() 的子 Agent、类型化 const AgentDefinition、createSdkMcpServer 和 4 种 options.mcpServers 配置字面量）、OpenAI Agents SDK（tool({...}) 工厂、new Agent({...}) 和 Agent.create({...})、9 种托管工具 工厂、跨 3 种传输方式的 MCP 服务类以及 MCPServers 包装器、4 种 defineX 防护机制工厂，以及 MemorySession / OpenAIConversationsSession / OpenAIResponsesCompactionSession 会话类——以上均由从 @openai/agents、@openai/agents-core 或 @openai/agents-openai 的导入进行门控）、Google ADK（new FunctionTool({...}) 构造函数、5 种 Agent 构造函数——new LlmAgent({...}) / SequentialAgent / ParallelAgent / LoopAgent / RoutedAgent——13 种托管工具类，以及 subAgents 边——以上均由从 @google/adk 的导入进行门控）、LangChain / LangGraph（tool(fn, {...}) 工厂、DynamicStructuredTool / DynamicTool，以及 createReactAgent / createAgent / new AgentExecutor ——由 @langchain/* / langchain / langgraph 生态系统进行门控）， 以及 Vercel AI SDK（tool({...}) / dynamicTool({...}) 单对象工厂、 基于调用的 generateText / streamText / generateObject / streamObject Agent，以及类 ToolLoopAgent / Experimental_Agent；tools 会作为对象/记录遍历，同时还支持 <provider>.tools.*() 托管工具——由裸 ai 导入进行门控）。 支持 .ts / .tsx / .mts / .cts，以及 JavaScript .js / .jsx / .mjs / .cjs，使用 tree-sitter-typescript 和 tree-sitter-tsx 语法（JavaScript 会路由至 tsx 语法——它是 JavaScript 的超集——并由相同的 language: typescript 规则包 审计）。 TypeScript 规则包涵盖 Claude Agent SDK （CSDK-010/011/012/013/014/016 工具规则；CSDK-120/130/131 Agent 规则）、 OpenAI Agents SDK（OAI-016/017/019/022/024 工具规则；OAI-105/116 Agent 规则）、Google ADK（ADK-013/015/016 工具规则；ADK-109 Agent 规则）、MCP （MCP-011/012/013/014 工具规则）、LangChain（LC-010/011/012/013/014 工具 规则；LC-111 Agent 规则），以及 Vercel AI SDK（VAI-001..008 工具/Agent 规则；VAI-012 仓库规则）。对于这些 SDK 中的任何一个，TypeScript 仓库 都不再会一概产生 META-004；完整矩阵请参阅 COVERAGE.md。 JavaScript（.js / .jsx / .mjs / .cjs）通过共享的 TypeScript 系列处理流水线进行 AST 解析：其工具和 Agent 会被发现并标记为 javascript，并由 language: typescript 规则包审计（可识别 ES import 和 CommonJS require() 绑定）。Go 使用 tree-sitter-go 发现 MCP 工具（mark3labs/mcp-go 和官方 modelcontextprotocol/go-sdk），并由 MCP 规则包中的 language: go 规则审计。C# 使用 tree-sitter-c-sharp 发现官方 ModelContextProtocol SDK 中带有 [McpServerTool] 的方法，并由 language: csharp 规则审计。PHP 使用 tree-sitter-php 发现带有 #[McpTool] 属性的方法（官方 mcp/sdk 和社区项目 php-mcp/server），并由 language: php 规则审计。Rust 使用 tree-sitter-rust 发现官方 rmcp crate 中带有 #[tool] 属性的方法（描述从 description = "..." 参数或 /// 文档注释中读取），并由 language: rust 规则审计；Recon 可以识别其他 Go、.NET、PHP 和 Rust SDK 的文件，但尚未对其进行 AST 解析。 规则架构中的 language: 字段用于控制各语言的规则集。

范围边界

• LLM 增强是独立的扫描后步骤（trustabl enrich）。 基于规则的检测（trustabl scan）不会进行网络调用——扫描本身不涉及 LLM。trustabl enrich 会读取扫描输出，并通过 BYOK 调用配置的 LLM 提供商（Anthropic、OpenAI 或 Google Gemini）（密钥通过 trustabl llm key set 存储在 ~/.config/trustabl/keys.json，权限模式为 0600）。每次调用都设有请求超时；只有当文件当前内容仍与模型审查过的内容一致时，--apply 才会重写文件（并先创建 .trustabl.bak 备份）——过期的扫描结果会被跳过，绝不会错误应用。启用 --langsmith（需提供 LANGSMITH_API_KEY）后，工具范围内的发现还会依据从 LangSmith 项目采样的运行时跟踪证据进行验证：每个被标记工具的错误率、延迟和近期错误消息会作为 trace_evidence 附加到输出中，并与静态代码片段一同提供给 LLM；没有跟踪历史的工具则会按发现项退回到纯静态增强。
• 置信度分数是启发式的，并非由 LLM 评判，也尚未使用带标签的真实 Agent 语料进行校准——请将发现结果视为调查线索。
• CLI 是唯一入口。 没有 Web 应用、API 服务或托管服务：可将 --format json 或 --format sarif 的输出传入自己的自动化流程。在 GitHub Actions 中，trustabl/trustabl-action 可封装扫描流程并替你将 SARIF 上传到 Security 选项卡；对于其他 CI，--format sarif --output <file> 会生成 SARIF 2.1.0 报告，可供 github/codeql-action/upload-sarif 或任何支持 SARIF 的步骤使用。
• Trustabl 采用开放核心模式。 此处记录的所有功能均采用 Apache-2.0 许可，且完整满足其用途：扫描无需密钥和网络，自带修复使用你自己的 LLM 密钥。策略生成、合规性映射和签名治理快照属于 Trustabl Console，这是单独的商业产品。完整的功能划分请参阅 docs/open-source-vs-console.md。

产出内容

trustabl scan 只检测并报告：它不会写入或修改所扫描仓库中的任何文件。只有选择运行 trustabl enrich --apply 时才会应用修复。每次运行都会生成一个 ScanResult，其中包含：

• 发现项 — 每条规则命中对应一项，每项都包含 severity、confidence、explanation、suggested_fix，以及命中位置（工具文件/行、Agent 调用点、子 Agent 文件或清单）。测试路径文件中的发现项会带有 "origin": "test"，默认不计入评分和退出代码 — 详见下文的“测试路径发现项”。

• 各表面就绪度评分（每个已发现的工具、Agent、子 Agent，或整个仓库各一项），以及总体评分（考虑覆盖广度并按问题严重程度加权的平均值 — 薄弱表面会更大幅度地拉低评分，但单个较差表面不会让评分归零；该评分用于确定处理优先级，不是 CI 门槛）。

• 已发现的清单 — 工具、Agent、托管工具、MCP 服务、子 Agent、技能、斜杠命令、插件清单和 Claude 设置 — 在顶层提供，供 CI 使用者使用。

• 可观测性信号（observability）— 在代码中发现的埋点，每条事实对应一条记录：供应商（OpenTelemetry、Langfuse、Logfire、Phoenix/OpenInference、OpenLLMetry、Braintrust、Weave、AgentOps、MLflow、Datadog LLM Observability、LangSmith），以及它只是导入还是已实际初始化，并附有文件和行号。这一区别正是关键：仓库导入了追踪 SDK 却从未启动它，在清单中看起来已埋点，实际上却不会产生任何追踪记录。仅对 Python 和 TypeScript/JavaScript 进行静态检测 — Trustabl 不会采集运行时追踪记录。

• 进程标签（otel_labels）— 在代码中发现的 agent-reliability-otel-labels 调用（导入、Run 构造、运行开始、工具跨度标签、运行结束），以及手动写入的任何 trustabl.* 标签键，并附有文件和行号，以及 OBS-006..012 规则读取的事实：Run 是否共享、工具失败时是否仍会运行标签、attempt 是否为固定数字，以及字面量 side_effect / exit_reason 值。仅支持 Python 和 TypeScript/JavaScript。不计入扫描 ID。

• 服务入口点（entrypoints，无入口点时省略）— 服务框架为外部请求或任务调用的 Python 函数：FastAPI 和 Flask 路由处理程序（kind: http，若存在则包含字面量 route），以及 Celery 任务 / Dramatiq actor（kind: worker）。仅记录事实：目前还没有规则使用这些信息。不会记录 examples/、demo/、docs/ 等类似目录下的入口点。

摘要中的工具表面分类

人类可读的格式会如实区分人们常常混为一谈的三类内容：

Tool definitions:   2  (custom tools with function bodies — scored below)
Agent tool grants: 14  (tool names the agent may call — audited by agent-scope rules)
Hosted tools:       1  (...)

只有“工具定义”类别会进入工具范围规则（这些定义包含规则可以读取的函数体）。Agent 授权和托管实例是 Agent 范围规则的输入，并非未经分析 — 它们只是不显示在各表面的就绪度表中。

输出模式

--format human（默认）会将人类可读的摘要输出到 stdout，并将实时 进度输出到 stderr——在交互式终端上显示动画旋转图标和进度条，在管道 中则显示纯 [phase] summary 行（适合 CI）。

--format json 会序列化完整的 ScanResult，以便通过管道传入你自己的 自动化流程。

--format sarif 会输出 SARIF 2.1.0 文档，适用于 github/codeql-action/upload-sarif 和其他支持 SARIF 的工具。建议的 修复方案保存在规则级别（help.text）；Trustabl 不会输出逐条结果的 fixes[]，因此该文档可以通过 GitHub 代码扫描的架构验证器（它会拒绝 缺少 artifactChanges 的 fix）。

--json-out <file> 和 --sarif-out <file> 会将 JSON / SARIF 文档写入文件， 不受 --format 影响——一次扫描可以将人类可读的摘要输出到 stdout， 同时将两种机器可读产物写入文件。文件字节与对应的 --format stdout 输出完全相同。

--bom-out <file> 还会额外写入字节稳定的 CycloneDX 1.5 BOM，其中包含 仓库声明的所有受支持语言的依赖——requirements.txt / pyproject.toml / Pipfile（pip）、package.json（npm）、go.mod（Go）、 composer.json（Composer）、*.csproj（NuGet）、Cargo.toml（Cargo）。它仅 盘点已声明的直接依赖，不会发起网络请求。如果清单包含 license 字段 （package.json、Cargo.toml、composer.json、pyproject.toml），则会将 SPDX 标识符包含在 BOM 中各组件的 licenses[] 数组内。

--vuln-scan 会将该 BOM 转化为漏洞判定：它将仓库中明确固定版本的依赖 与固定的 OSV 快照进行匹配，并将每个受影响的软件包作为 发现项报告，其中包含公告 ID（CVE / GHSA / PYSEC / …）、由 CVSS 推导的 严重性以及首个修复版本——因此，存在漏洞的依赖会通过常规严重性门槛和 退出代码导致扫描失败，并与规则发现项一同写入 JSON / SARIF 输出中的 ScanResult.vulnerabilities。与扫描的其他部分不同，此功能需显式启用， 且需要联网：首次使用时会从 osv.dev 获取 OSV 快照，将其缓存在你的用户 缓存目录下，之后优先使用缓存——后续的 --vuln-scan 会复用缓存数据库 （不会重新下载），直到缓存超过 24h，因此重复扫描速度快，且可离线运行。 trustabl vulndb pull 可按需刷新缓存；--no-rules-update 会固定使用 缓存，无论其新旧（完全离线）。仅匹配明确固定的版本 ——声明范围（^1.0、>=2）在没有锁文件时无法解析为单个版本，因此不会 进行匹配，而不是猜测。只有启用 --vuln-scan 时，快照版本才会纳入 ScanID，因此结果会如实反映生成该结果所用的漏洞数据，而默认扫描仍与 之前完全保持字节一致。

将 --vuln-scan 与 --bom-out 结合使用，会将 CycloneDX 文档从纯清单升级为 BOM 加 VEX：匹配到的公告会以 CycloneDX 1.5 的 vulnerabilities[] 数组 形式输出——每项都包含公告 ID、OSV source、严重性 rating、升级 recommendation，以及一个将其关联到受影响组件 bom-ref 的 affects[] 引用——因此，一条 trustabl scan ./repo --vuln-scan --bom-out bom.json 命令 即可生成基于标准的产物，供任何支持 CycloneDX 的工具读取。未启用 --vuln-scan 时，会省略 vulnerabilities[] 数组，BOM 保持为纯清单。

--format json 和 --format sarif 不输出进度，且在输入相同的运行之间 保持字节稳定（是 ScanResult 的纯函数）。人类可读格式则有意不保证字节 稳定：其 ANSI 颜色会根据终端自动检测（TTY 与管道、NO_COLOR），因此同一扫描 可能带颜色，也可能不带颜色。当字节稳定性很重要时，请使用 --no-color， 或对 JSON/SARIF 输出进行差异比较。

测试路径发现项

文件位于测试路径（tests/、__tests__/、testdata/、test_*.py、*_test.go、*.spec.ts 等）下的发现项仍会以所有格式报告——不会被悄悄隐藏——但默认情况下，不会计入就绪度评分，也不会导致构建失败：在 tests/test_adapter.py 中声明的 WebSearchTool 与生产 Agent 中随代码发布的同类发现项并不相同，而对它们进行同等评分会让报告失去可操作性。每个此类发现项在 JSON 中都带有 "origin": "test"，在 SARIF 中带有 origin 属性和一个 result.suppressions 条目（不会显示在 GitHub 代码扫描的默认告警视图中，但仍保留在原始日志中），并会显示在人工可读输出末尾的“测试路径发现项（不计分）”部分，而不会混入上方参与评分的分组。

传入 --include-test-paths，即可像处理其他发现项一样对这些发现项进行评分并使其导致构建失败——如果项目确实会在形似 tests/ 的路径下发布代码，这个选项就很有用。

诊断信息（--verbose / --debug）

--verbose（-v）会在 stderr 上显示扫描过程：规则来源信息（仓库、引用、解析后的 SHA，以及任何缓存回退）、各阶段的发现数量（语言、工具、Agent、检测到的 SDK、已加载的检测器、未经审计的 SDK）、输出目标，以及最终结果摘要（扫描 ID、评分、按严重级别统计的发现数量、退出代码）。--debug 会显示 --verbose 的全部内容，并额外提供各阶段的耗时，以及数量受限的实体／发现详情（每个发现的工具／Agent，以及每项带有 file:line 的发现）。

这两个都是全局标志——可用于 scan、mcp 和 rules pull，也可以放在子命令前后（trustabl -v scan … 或 trustabl scan -v …）。--debug 隐含启用 --verbose。两者都只写入 stderr，因此不会影响 stdout 中的报告，也不会破坏 JSON/SARIF 字节稳定性约定：--format json --debug 仍会在 stdout 上输出纯净文档，同时将诊断信息写入 stderr。诊断信息的颜色遵循与报告相同的规则（在 --no-color、NO_COLOR 启用时，或 stderr 不是终端时关闭）。动画进度面板与交错的日志行在同一个 stderr 上会相互干扰，因此 --verbose/--debug 会自动将进度显示为普通的 [phase] 行，而不是实时旋转指示器。

将诊断信息保存到文件。 没有专门的 --log-file 标志——由于诊断信息属于独立输出流（stderr），重定向 stderr 是预期的做法：

# Report and diagnostics to separate files (stdout vs stderr)
trustabl scan ./repo --debug --format json >report.json 2>diagnostics.log

# Human report on screen, diagnostics to a file
trustabl scan ./repo --debug 2>diagnostics.log

# Everything (report + diagnostics) in one file
trustabl scan ./repo --debug &>everything.log

使用 --format json/sarif 时，进度显示会关闭，因此 stderr 文件中只有诊断信息；使用 --format human 时，文件中还会包含普通的 [phase] 进度行。

退出代码（除非设置了 --include-test-paths，否则测试路径发现不会纳入此判断——参见上文“测试路径发现”）：

• 0 — 没有严重级别 ≥ medium 的发现（或完全没有发现）。
• 1 — 至少有一项严重级别 ≥ medium 的发现，或设置了 --strict 且存在任何发现。
• 2 — 扫描器／I/O 错误，或没有找到可用规则且无法获取任何规则（运行 trustabl rules pull），或签名频道（--rules-source）未通过验证（签名错误、密钥不受信任／已过期、频道混淆、声明已过期或回滚，或摘要不匹配）——Trustabl 会拒绝使用未经验证的规则运行。

仍会发现 OpenShell 攻击面（调用 shell 的函数、openshell/*.yaml 策略），并在 human 格式的 Risk surfaces: openshell 区块中报告：调用 shell 的函数数量、前三个 file:line 位置（确定性排序）、说明威胁模型的 why: 行（遭提示词注入的 Agent 若将其中任一项暴露为可调用工具，就能运行任意命令），以及列出具体补救措施的 fix: 行（使用沙箱、设置允许列表、移除 shell=True、避免在 Agent 可调用的代码中放置 shell 逻辑）。用于审计这些攻击面的 OSH-* 检测规则已移至闭源配套项目；由于未随附 OSH 规则，此类仓库不会触发规则，也不会产生 META 发现——该区块会明确呈现未经审计的风险，但不会声称已进行审计。OpenShell 属于风险攻击面，而不是 SDK，因此不会像未知 SDK 那样被标记为“未经审计”。

安装

使用 Homebrew、Scoop、Docker 或直接下载，安装 Agent Reliability Analyzer（trustabl CLI）。

Homebrew（macOS、Linux）

brew install trustabl/tap/trustabl

Scoop（Windows）

scoop bucket add trustabl https://github.com/trustabl/scoop-bucket
scoop install trustabl

Docker

docker run --rm -v "$PWD:/repo" ghcr.io/trustabl/trustabl:latest scan /repo

直接下载

从适用于你平台的发布页面下载预构建压缩包。每个版本都包含 checksums.txt 和构建来源证明；请使用以下命令验证：

gh attestation verify <archive> --repo trustabl/agent-reliability-analyzer

在仓库重命名之前发布的压缩包，只能在旧仓库标识（--repo trustabl/trustabl）下通过验证：Sigstore 证书会绑定签名时的仓库路径，因此记录的身份无法随重命名而更新。

Claude Code 插件

该插件会安装两个技能（trustabl-scan 和 trustabl-enrich）、一个 SessionStart 钩子和一个内置 MCP 服务，并会在首次会话时自动下载固定版本的 CLI 二进制文件（无需 sudo，不会触碰 Claude Code 插件 数据目录之外的任何内容）。

在 Claude Code 会话中使用 /plugin 斜杠命令进行安装：

/plugin install trustabl@claude-plugins-official

然后重新加载以激活：

/reload-plugins

安装后，mcp__trustabl__scan 工具可供直接调用，trustabl-scan 和 trustabl-enrich 技能会显示在技能选择器中，钩子则会在会话开始时确认二进制文件已就绪。使用 /plugin uninstall trustabl 卸载。

Claude Code Agent

独立子 Agent（trustabl）可交互式地运行完整的扫描 → 丰富 → 审核 → 应用流程。它不需要插件，只需确保 trustabl 二进制文件已在 PATH 中。将 Agent 文件复制到项目配置或主目录配置中：

# Project-level (scoped to this repo)
curl -fsSL https://raw.githubusercontent.com/trustabl/agent-reliability-analyzer/main/agents/trustabl.md \
  -o .claude/agents/trustabl.md

# Global (available in every project)
curl -fsSL https://raw.githubusercontent.com/trustabl/agent-reliability-analyzer/main/agents/trustabl.md \
  -o ~/.claude/agents/trustabl.md

安装后，可在 Claude Code 中通过 @trustabl 调用，或从子 Agent 选择器中选择。它会询问要扫描哪个目录，运行 trustabl scan 和 trustabl enrich，然后通过 diff 逐项引导你审阅拟议的修复。

丰富步骤需要 Anthropic API 密钥。调用 Agent 前请先设置：

export ANTHROPIC_API_KEY=sk-ant-api03-...   # or: trustabl llm key set

从源代码构建

需要 CGO_ENABLED=1，因为 AST 解析器使用 tree-sitter （Python + TypeScript + TSX 绑定），它是一个 C 库：

# macOS / Linux
CGO_ENABLED=1 go build -o trustabl ./cmd/trustabl

# Cross-compile: pick a C toolchain for the target. zig is the easiest.
CGO_ENABLED=1 CC="zig cc -target x86_64-linux-gnu" \
  GOOS=linux GOARCH=amd64 go build -o trustabl-linux ./cmd/trustabl

这是为了使用 tree-sitter 进行精确 AST 解析所付出的代价。如果之后必须提供单二进制、无 CGO 的发行版，Python 的替换目标是 github.com/go-python/gpython（对现代 Python 的保真度较低）；TypeScript 则需要单独寻找替代方案。

证明

测试用法示例

前置条件和设置：

安装 cosign（任意 2.x 或 3.x 版本均可——Trustabl 会适配已安装的版本）

添加到目标文件夹路径：

export PATH="<folder_path>:$PATH"

导出并生成密钥对：

export COSIGN_PASSWORD="" 跳过口令提示（真实密钥请勿省略）

cosign generate-key-pair 生成 cosign.key（私钥）和 cosign.pub（公钥）

Trustabl 扫描并生成证明：

./trustabl.exe scan https://github.com/google/adk-samples --json-out report.json --attest --attest-key cosign.key --attest-bundle att.bundle.json --attest-no-tlog

验证

./trustabl.exe verify report.json --key cosign.pub --bundle att.bundle.json --no-tlog

无密钥（CI / 无需管理密钥）

无密钥模式使用当前环境中的 OIDC 身份进行签名，而不是使用密钥对——无需生成或存储密钥。在 CI（GitHub Actions）中会自动使用运行器的身份；在笔记本电脑上则会打开浏览器供你登录。无论哪种情况，签名事件都会记录在公开的 Rekor 透明日志中——如果无法接受这种可见性，请使用上面的密钥模式。此处不使用 --no-tlog（无密钥模式就是透明日志路径），因此 cosign v2/v3 的差异不适用。

扫描并生成证明（无密钥）：

./trustabl.exe scan https://github.com/google/adk-python --json-out report.json --attest --attest-bundle att.bundle.json

验证（无密钥——必须固定签名者和签发者）：

./trustabl.exe verify report.json --bundle att.bundle.json --certificate-identity "<signer-identity>" --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

在 GitHub Actions 中，身份是工作流引用，例如 https://github.com/OWNER/REPO/.github/workflows/scan.yml@refs/heads/main。

cosign（可选——仅用于扫描证明）

Trustabl 的 attest / verify 命令和 scan --attest 会调用 cosign CLI—— cosign 负责签名和验证，Trustabl 不附带自己的密钥。仅当你使用证明功能时才需要它；普通的 scan 不会调用它。

# macOS / Linux
brew install cosign
# Windows
scoop install cosign

在 CI 中无需手动安装——Trustabl GitHub Action 和 GitLab 组件会为你添加 sigstore/cosign-installer。

使用证明进行扫描 — 分步说明（密钥模式，离线）

密钥模式使用本地密钥对签名，并跳过公共透明日志——无需浏览器或网络，非常适合在笔记本电脑或隔离环境中运行。

**cosign 版本：**兼容 cosign 2.x 和 3.x——Trustabl 会根据版本自动选择合适的无透明日志机制（v2 使用 --tlog-upload=false；v3+ 使用不依赖 Rekor 的 --signing-config，因为该版本已移除此标志）。通过 PATH 安装时，命令为 trustabl；本地 Windows 构建的命令为 .\trustabl.exe。

证明层级：这是免费层级的基本证明——它会为扫描来源信息（扫描 ID、规则版本、可靠性评分、判定结果、严重程度计数）签名。行为和策略感知证明已列入付费路线图。

步骤 0 — 安装 cosign（请参阅上文适用于你操作系统的命令）。

步骤 1 — 生成签名密钥对：

export COSIGN_PASSWORD=""        # skip the passphrase prompt (omit for a real key)
cosign generate-key-pair         # writes cosign.key (private) + cosign.pub (public)

步骤 2 — 扫描并一步完成签名：

trustabl scan https://github.com/google/adk-samples \
  --json-out report.json \
  --attest --attest-key cosign.key --attest-bundle att.bundle.json --attest-no-tlog

会写入 report.json（扫描结果）、trustabl-predicate.json 和已签名的 att.bundle.json。退出代码为 1 仅表示存在发现项——仍会写入签名包（它会为判定结果签名，无论通过还是未通过）。

步骤 3 — 验证（使用方）：

trustabl verify report.json --key cosign.pub --bundle att.bundle.json --no-tlog

Verified OK，退出代码为 0——报告真实有效且未被篡改。

步骤 4 —（可选）验证篡改检测：

echo '{"tampered":true}' >> report.json
trustabl verify report.json --key cosign.pub --bundle att.bundle.json --no-tlog

现在验证会失败（退出代码为 1）：签名与报告的确切字节绑定，因此任何修改都会被检测到。

无密钥签名（无需管理私钥）是 CI 中的默认方式，适用于存在环境 OIDC 身份的情况；它还会将签名记录到公共 Rekor 透明日志中。完整命令说明请参阅使用。

使用 — 运行首次 Agent 可靠性扫描

# Local repo
trustabl scan ./path/to/agent-repo

# GitHub repo (shallow clone to temp dir, removed on exit)
trustabl scan https://github.com/org/repo

# Restrict detectors
trustabl scan ./repo --detectors claude_sdk
trustabl scan ./repo --detectors openai_sdk
trustabl scan ./repo --detectors google_adk
trustabl scan ./repo --detectors claude_sdk,openai_sdk,google_adk
# --detectors openshell is accepted but selects zero rules (pack is closed-source now)

# Agent Skill security (SKILL.md) — flags unrestricted allowed-tools (a bare
# `Bash` grant), pre-model dynamic-context exec, bundled-script network egress /
# secret reads, committed secrets, hidden-Unicode prompt injection, and a
# description that claims read-only while granting side-effecting tools (the
# CSKILL-* rules). Skills are discovered and scanned automatically.
trustabl scan ./repo                              # scans skills alongside tools/agents/MCP
trustabl scan ./repo --detectors claude_skill     # only the Agent Skill (CSKILL-*) rules
trustabl scan ./path/to/my-skill                  # point straight at one skill's directory

# Dependency BOM (supply chain): export the repo's DECLARED deps across all
# supported languages (pip / npm / Go / Composer / NuGet / Cargo manifests) as a
# CycloneDX SBOM, to hand to OSV-Scanner / Dependabot / syft. Pure inventory —
# the scan itself does no CVE lookup.
trustabl scan ./repo --bom-out sbom.json

# Vulnerability scan (opt-in, online): match the repo's pinned deps against the
# OSV database and FAIL on known CVEs — advisory id, CVSS severity, fixed version.
trustabl vulndb pull                              # pre-download OSV (optional; --vuln-scan auto-fetches)
trustabl scan ./repo --vuln-scan                  # BOM inventory + CVE verdict in one pass
trustabl scan ./repo --vuln-scan --bom-out bom.json  # CycloneDX BOM + VEX (vulnerabilities[]) in one file

# License scan (opt-in): flag dependencies with copyleft licenses (GPL-2.0,
# GPL-3.0, AGPL-3.0, LGPL-2.1, SSPL-1.0) as medium-severity findings.
# License data is read from the manifest at parse time — no network call.
trustabl scan ./repo --license-scan
trustabl scan ./repo --license-scan --bom-out bom.json  # findings + BOM with licenses[]

# Secret scan (opt-in): walk all text files in the repo for hardcoded
# credential literals (SECRET-LIT-001, high) and scripts that read
# credential environment variables (SECRET-ENV-001, medium).
trustabl scan ./repo --secret-scan

# Test-path findings (a tests/ agent, test_*.py, *.spec.ts, …) are always
# reported but excluded from scoring and the exit code by default — see
# "Test-path findings" below. --include-test-paths scores and fails on them
# like any other finding.
trustabl scan ./repo --include-test-paths

# JSON output for CI piping
trustabl scan ./repo --format json

# SARIF output for GitHub Code Scanning / SARIF-aware tools
trustabl scan ./repo --format sarif > trustabl.sarif

# Write the report to a file instead of stdout (any format). --output writes
# the file even when the scan exits 1 on findings, so a CI step can upload it.
trustabl scan ./repo --format sarif --output trustabl.sarif

# One scan, both machine artifacts written to files (human summary to stdout)
trustabl scan ./repo --json-out trustabl.json --sarif-out trustabl.sarif

# Exit 1 on any finding regardless of severity
trustabl scan ./repo --strict

# --- Attestation (opt-in; requires the cosign CLI on PATH) -------------------
# Sign the JSON report into a cosign attestation of the SCANNED repo's result.
# Keyless by default: in CI it uses the runner's ambient OIDC identity (no keys
# to manage) and logs the signing event to the PUBLIC Rekor transparency log.
trustabl scan ./repo --json-out trustabl.json --attest
trustabl attest trustabl.json                       # same, as a separate step
# Offline / private signing with a key (no public transparency log):
trustabl attest trustabl.json --key cosign.key --no-tlog
# Verify (run where you CONSUME the attestation). Keyless pins who signed + issuer:
trustabl verify trustabl.json \
  --certificate-identity https://github.com/OWNER/REPO/.github/workflows/scan.yml@refs/heads/main \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
trustabl verify trustabl.json --key cosign.pub --no-tlog   # key-mode, offline

# Download / refresh the detection rule packs into the local cache
trustabl rules pull

# Validate a local rule-pack directory against this build's schema (CI gate
# for the agent-reliability-rules repo — strict-loads every pack, fails on the first error)
trustabl rules validate ./agent-reliability-rules

# Use a custom rules repo, or pin a specific released ruleset (env: TRUSTABL_RULES_REPO).
# Default pulls the latest reviewed rules from agent-reliability-rules main; pin a tag for stability.
trustabl scan ./repo --rules-repo https://github.com/org/my-rules
trustabl scan ./repo --rules-ref v0.1.0

# Air-gapped / offline: skip the network fetch, use the cached rules only
trustabl scan ./repo --no-rules-update

# Progress output (human format): animated on a terminal, plain lines when piped
trustabl scan ./repo                 # spinner + bars on a TTY; "[phase] summary" lines when piped
trustabl scan ./repo --no-progress   # disable progress entirely

# Diagnostics on stderr (global flags; stdout/report unaffected)
trustabl scan ./repo --verbose       # -v: rule provenance, discovery counts, result summary
trustabl scan ./repo --debug         # + per-phase timing and per-entity/per-finding detail
trustabl scan ./repo --debug --format json > out.json   # clean JSON on stdout, diagnostics on stderr

# Run as a stdio MCP server so an MCP client (Claude Code, Cursor, Claude
# Desktop) can scan code an agent just wrote (see "Run as an MCP server" below)
trustabl mcp

# Configure LLM provider, then enrich a scan result with AI explanations and fixes
export ANTHROPIC_API_KEY=sk-ant-api03-...  # preferred: env var (works in CI, no setup)
trustabl llm list                          # show configured providers with masked keys
trustabl llm key set                       # prompt securely for an API key (persistent)
trustabl llm key set sk-ant-api03-...      # set key non-interactively
trustabl llm key get                       # show masked key for active provider
trustabl llm key delete                    # delete key with confirmation prompt
trustabl llm model set claude-sonnet-4-6   # change model for active provider
trustabl llm base-url set http://host:4000 # set API base URL (only meaningful for "custom")
trustabl llm provider set openai           # switch active provider (auto-creates entry)
trustabl llm provider list                 # list configured providers

# Self-hosted / local model server (any OpenAI-compatible endpoint, e.g. a
# LiteLLM or vLLM gateway). Two ways to configure it:
#
# 1. Env vars — no persistent config, works in CI:
#    OPENAI_BASE_URL alone activates "custom", ahead of a plain OPENAI_API_KEY.
#    No default model, so TRUSTABL_LLM_MODEL is required. OPENAI_API_KEY is
#    optional: only set it if the endpoint actually checks it.
export OPENAI_BASE_URL=http://localhost:4000
export TRUSTABL_LLM_MODEL=qwen-32b
#
# 2. Persistent config — same three fields, saved to ~/.config/trustabl/keys.json:
trustabl llm provider set custom
trustabl llm base-url set http://localhost:4000
trustabl llm model set qwen-32b
# trustabl llm key set is optional — skip it if the endpoint needs no key

# Enrich a scan result (requires any configured LLM provider — a custom
# endpoint may not need a key, every other provider does)
trustabl scan ./myrepo --format json | trustabl enrich --repo ./myrepo        # pipe scan into enrich (stdout)
trustabl enrich --input scan.json --repo ./myrepo --output enriched.json      # file in, file out
trustabl enrich --input scan.json --repo ./myrepo --diff                      # preview proposed fixes as a unified diff (stderr)
trustabl enrich --input scan.json --repo ./myrepo --diff --apply              # preview and apply fixes
trustabl enrich --input scan.json --repo ./myrepo --apply                     # apply fixes without previewing
trustabl enrich --input scan.json --repo ./myrepo --rule CSDK-010             # focus on one rule
trustabl enrich --input scan.json --repo ./myrepo --only-enriched             # CI: only enriched findings

# Ground tool findings in LangSmith runtime traces (opt-in; error rates, latency,
# recent errors are fetched per flagged tool and fed to the LLM as evidence)
export LANGSMITH_API_KEY=lsv2_...          # BYOK; LANGSMITH_ENDPOINT overrides for self-hosted
trustabl enrich --input scan.json --repo ./myrepo --langsmith                  # project: $LANGSMITH_PROJECT or "default"
trustabl enrich --input scan.json --repo ./myrepo --langsmith --langsmith-project prod

规则会缓存在操作系统的缓存目录下（os.UserCacheDir()；例如 Windows 上的 %LocalAppData%\trustabl\rules\，Linux 上的 ~/.cache/trustabl/rules/）。首次扫描（或显式执行 trustabl rules pull）会填充缓存；之后每次扫描都会先检查更新（除非指定 --no-rules-update），若获取失败，则回退到缓存的规则。

已签名规则渠道（默认）。直接执行 trustabl scan 时，会从经签名验证的生产发布渠道解析规则：Trustabl 会使用内置的信任密钥环验证已签名的渠道声明，获取其指定的规则包；若验证失败，则拒绝运行未经验证的规则（退出代码为 2）。显式指定 --rules-source git 可选择未签名的 git 路径；指定 --rules-repo / --rules-ref 也会自动选择该路径；如需测试已签名的分支，仍可使用 --rules-source <name> --rules-repo <fork> 指向该分支。（--channel <name> 是 --rules-source <name> 的已弃用别名。）默认扫描现在使用已签名的生产渠道；在 CI 中设置 TRUSTABL_REQUIRE_SIGNED=1（或使用 --require-signed）可完全禁止回退到未签名的 git 路径。已发布的切换前二进制不受影响（默认值和密钥环均已编译其中）；升级后，由于来源标签和 git SHA 变为渠道规则包摘要，ScanID 会变化一次。未使用获准生产规则的扫描（使用预发布渠道或自定义 --rules-repo 来源）会在报告和 JSON rules_origin 字段中加注标记，其来源信息也会纳入 ScanID。此构建内置了规则签名公钥，因此使用已签名的 --rules-source 时会运行验证流程；只有在确实验证失败时（签名无效、密钥不受信任或已过期、渠道不匹配、声明已过期或发生回滚，或摘要不匹配）才会拒绝运行（退出代码为 2）。

编码前约束（trustabl forge）

trustabl forge 是 trustabl scan 的对应工具：它不会在代码编写后审计代码，而是生成一个整合后的预编码 SKILL.md，在 Agent 编写任何代码之前告知它应避免哪些模式。生成的技能按 SDK 和作用范围（工具、Agent、子 Agent、仓库、技能）组织规则，并按严重程度排序，让风险最高的约束优先显示。

SDK 检测的工作方式。 Forge 会扫描目标的依赖清单——pyproject.toml、requirements.txt、Pipfile、poetry.lock、package.json 和 go.mod——以确定要包含哪些 SDK 策略包。这与 trustabl scan 在侦察步骤中执行的轻量级依赖文件检查相同：不解析 AST、速度快，且可安全用于任何仓库。如果找不到清单（或清单中没有声明受支持的 SDK），forge 会以状态码 1 退出，并告知你通过 --policy 传入策略。

语言检测。 同样的清单会告诉 forge 每个 SDK 是用哪种语言声明的：pyproject.toml、requirements.txt、Pipfile 和 poetry.lock 表示 Python，package.json 表示 TypeScript，go.mod 表示 Go。由此选择运行时追踪部分中的语言内容。传入 --lang python,typescript,go 可添加语言。--lang 不会选择规则包，因此尚无清单的新仓库也需要使用 --policy（见下方最后一个示例）。相同的语言也会用于筛选规则部分：如果某个 SDK 仅在 go.mod 中声明，则只会包含该 SDK 的 Go 规则和适用于所有语言的规则。因此，仅使用 Go 的 Google ADK 仓库会获得 Go 追踪方案、与语言无关的 ADK 规则，以及一条说明目前尚无 Go 专属 ADK 规则的提示。仅通过 --policy 指定的类别，或虽在清单中声明但 forge 无法放置的类别（例如 composer.json），会保留其所有规则。

# Auto-detect SDKs from the current directory
trustabl forge

# Auto-detect from a specific repo path
trustabl forge /path/to/repo

# Add a policy on top of auto-detected SDKs — useful when introducing a new
# SDK that is not yet in the dependency manifest
trustabl forge --policy openai_sdk
trustabl forge /path/to/repo --policy claude_sdk,mcp

# Write the generated SKILL.md to a file instead of stdout
trustabl forge -o .claude/skills/trustabl-pre-coding/SKILL.md

# Pin a specific rules version (same as trustabl scan --rules-ref)
trustabl forge --rules-ref v0.3.0

# Backward-compatible: generate only the Agent Skill (CSKILL-*) rules
trustabl forge --policy claude_skill

# New Go repo with no go.mod yet
trustabl forge --policy google_adk --lang go

可用的策略类别（传给 --policy）：

类别	SDK / 框架
claude_sdk	Claude Agent SDK（Python + TypeScript）
openai_sdk	OpenAI Agents SDK（Python + TypeScript）
google_adk	Google Agent Development Kit（Python + TypeScript）
mcp	Model Context Protocol 服务
langchain	LangChain / LangGraph（Python + TypeScript）
crewai	CrewAI（Python）
pydantic_ai	Pydantic AI（Python）
vercel_ai	Vercel AI SDK（TypeScript）
autogen	AutoGen / AG2（Python）
claude_skill	Claude Code 技能（SKILL.md）
raw_llm_sdk	裸用 anthropic / openai 客户端工具循环（非 Agent 框架）
agent_config	提交到仓库的 Harness 配置：在文件夹受信任之前运行代码或授予权限（.claude/settings.json、.mcp.json、.gemini/.env、.vscode/settings.json、.codex/config.toml）
ci	从 GitHub Actions 工作流（.github/workflows/*.yml）中运行的编码 Agent，响应任何 GitHub 用户都能触发的事件
openshell	Shell 调用工具（当前策略包中没有规则）

多个类别以逗号分隔：--policy openai_sdk,mcp。

输出内容。 生成的文件是有效的 SKILL.md，包含：

• 一个 frontmatter 块（name: trustabl-pre-coding、allowed-tools: Read、 disable-model-invocation: false）。
• 一个被动印章注释，其中包含规则 SHA、日期、架构版本、模板（布局）版本和检测到的 SDK 列表 —— 这样你就能确切知道生成该文件所用的规则集和布局，以及何时需要重新生成。
• 印章后紧接着是 ## How to Apply These Constraints 约束应用循环部分：一个静态的四步流程，告诉模型将自己编写的每个定义与对应约束进行核对、按规则 ID 指出任何违规、应用该规则的指令，并记录修复过程。这是模型执行的自检 —— 它不会自行运行 trustabl scan；扫描生成的代码仍是独立步骤。
• 一个 ## Runtime Tracing 部分：说明如何让 Agent 发出 OpenTelemetry spans，然后如何使用 agent-reliability-otel-labels 为其添加标签（运行标识、步骤顺序、工具调用指纹、重试次数、副作用类别、退出原因）。每种选定语言都有一个代码块（Python、TypeScript、Go），并提供针对 Google ADK（Python、Go）、Vercel AI SDK（TypeScript）、Pydantic AI（Python）、OpenAI Agents SDK（Python、TypeScript）、LangChain / LangGraph（Python）、CrewAI（Python）、AutoGen（Python）和 MCP 客户端会话（Python）的已验证配置。其他框架仅提供语言代码块。不涵盖非 OpenTelemetry 跟踪技术栈。若未检测到受支持的语言，则省略此部分；若 claude_skill 是唯一类别，也会省略此部分（Agent Skills 是 SKILL.md 文件，并非需要跟踪的 Agent 代码）。
• 每个检测到的 SDK 各有一个 ## SDK Name 部分，其中包含 ### Tool Rules、### Agent Rules、### Subagent Rules、### Repo Rules 和 ### Skill Rules 子部分（省略空子部分）。
• 每条规则的内容块：指令（修复方法，第一句）、原因（说明，第一句）、适用条件、严重程度和置信度。

将输出放入 Agent 仓库的 .claude/skills/trustabl-pre-coding/SKILL.md，Claude Code 就会在编写任何 Agent 代码之前自动调用它。添加新的 SDK 依赖、拉取规则更新，或升级到使用更新模板的 forge 版本后，请重新运行 trustabl forge —— trustabl forge check 会报告这两种原因导致的过时状态。

持续集成

支持两种 CI 模式，且可以组合使用：

• 将构建设为门禁。 退出代码就是门禁：无问题时为 0，发现中等或更高严重程度的问题时为 1（--strict 会将门槛降至任何问题），发生操作错误时为 2。在作业步骤中直接运行 trustabl scan ./repo，应当会在需要失败时令作业失败。
• 发布到 GitHub Code Scanning。 在 GitHub Actions 上，trustabl/trustabl-action 会在单个步骤中运行扫描并将 SARIF 上传到仓库的 Security 选项卡（upload-sarif 默认值为 true），提供 PR 内联提醒和可选的阈值门禁 —— 这是推荐方式，也是工作流的唯一事实来源。在 GitHub Actions 之外，--format sarif --output <file> 会生成 SARIF 2.1.0 报告，可由任何 github/codeql-action/upload-sarif 或兼容 SARIF 的步骤发布。由于 --output 会在应用基于问题的退出代码之前写入文件，因此扫描步骤可以设置 continue-on-error: true，上传步骤则设置 if: always()，这样即使扫描发现问题，也能将其呈现出来，而不会中止运行且未上传任何内容。

SARIF 文档是扫描结果的纯函数：相同输入的多次运行会得到逐字节稳定的结果，文件 URI 相对于仓库，并且每个问题都有稳定的 partialFingerprints，因此 Code Scanning 会在多次运行之间对提醒去重，而不是重新打开它们。

作为 MCP 服务运行

trustabl mcp 会通过标准输入/输出运行 Model Context Protocol（MCP）服务，让 MCP 客户端（Claude Code、Cursor、Claude Desktop）能够扫描 Agent 刚刚编辑的目录并读取扫描结果。这与 trustabl scan 执行的是同一项扫描，只是将其作为 MCP 工具提供——不会打开网络端口。该服务通过标准输出使用 JSON-RPC，因此不会向其中写入其他内容；状态行和诊断信息会发送到标准错误。

它提供两个工具：

• scan — 输入 { "path": "<dir>", "rules_ref": "<branch-or-tag>"?, "vuln_scan": true? }。 扫描 path 并以 JSON 形式返回完整扫描结果（发现项、评分、发现的清单）——结构与 --format json 相同。将 vuln_scan: true 设为同时将声明的依赖项与固定版本的 OSV 快照进行匹配，并报告已知 CVE（与 --vuln-scan 一致；默认关闭）。
• version — 报告构建版本、提交和日期。

要注册该服务，请将 MCP 客户端配置为通过标准输入/输出使用带有 mcp 参数的二进制文件。Claude Code 的配置如下：

claude mcp add trustabl -- trustabl mcp

对于 Gemini CLI，请添加到 ~/.gemini/settings.json：

{
  "mcpServers": {
    "trustabl": {
      "command": "trustabl",
      "args": ["mcp"]
    }
  }
}

对于 OpenAI Codex，请添加到 ~/.codex/config.toml：

[mcp_servers.trustabl]
command = "trustabl"
args = ["mcp"]

或者直接在客户端的 MCP 配置中进行设置（Claude Desktop / Cursor 使用的 mcpServers 标准输入/输出结构）：

{
  "mcpServers": {
    "trustabl": {
      "command": "trustabl",
      "args": ["mcp"]
    }
  }
}

规则来源标志（--rules-repo、--rules-ref、--no-rules-update）在 trustabl mcp 中的作用与在 trustabl scan 中完全相同；客户端也可以在 scan 工具参数中传入单次调用的 rules_ref，它会覆盖该次调用的命令级 --rules-ref。

Claude Code 插件（生成时自检）

Trustabl 在 .claude-plugin/ 下提供了 Claude Code 插件，其中包含两个技能，可形成扫描和修复闭环：

• trustabl-scan — 在 Agent、工具、子 Agent 或 MCP 服务的代码编写或更改后立即触发，并调用 Trustabl 的 scan 工具（捆绑的 MCP 服务 mcp__trustabl__scan），在提交前、CI 之前对代码进行自检。
• trustabl-enrich — 接收 trustabl scan 的运行输出（JSON、SARIF 或粘贴的终端文本），并将每个发现项作为有针对性的代码编辑应用，完全依据扫描结果自身的 explanation 和 suggested_fix 字段进行指导。它不会重新运行扫描器；请先使用 trustabl-scan，然后将结果交给 trustabl-enrich。

扫描通过捆绑的 MCP 服务运行： .mcp.json 会注册一个名为 trustabl 的服务，其命令是一个启动脚本 (scripts/trustabl-mcp.sh)，该脚本提供 mcp__trustabl__scan 工具。启动脚本和 SessionStart 钩子（hooks/hooks.json → scripts/check-trustabl.sh）共用安装逻辑（scripts/lib-trustabl.sh），用于从 GitHub Releases 下载固定版本的 CLI，通过发布包中的 checksums.txt 验证文件，并将其安装到插件的专用数据目录（$CLAUDE_PLUGIN_DATA——无需 sudo，不会触及该目录以外的任何内容）。安装具有幂等性（仅在固定版本变更或副本缺失／损坏时重新运行）；启动脚本会在启动服务前同步完成安装，因此首次会话不会发生竞争。相同的二进制文件也会通过 $TRUSTABL_BIN 提供给 enrich 技能的直接 CLI 调用路径。当自动安装无法运行时（首次会话离线、平台不受支持，或缺少 curl／tar），则回退到 PATH 中的 trustabl；系统范围的安装仍是 trustabl-scan 中需要用户同意的步骤。该插件不会运行自己的网络服务，也不会修改扫描目标之外的任何内容。

Gemini CLI 扩展（生成时自审）

Trustabl 随附 Gemini CLI 扩展，位于 gemini-extension.json， 其中包含与 Claude Code 插件相同的两个技能。

先决条件。 请先安装 Trustabl 二进制文件——该扩展不会像 Claude Code 插件那样自动安装，因为 Gemini CLI 没有私有插件数据目录：

# macOS / Linux
brew install trustabl/tap/trustabl

# Windows
scoop bucket add trustabl https://github.com/trustabl/scoop-bucket
scoop install trustabl

安装扩展：

gemini extensions install https://github.com/trustabl/agent-reliability-analyzer

注册 MCP 服务，以便 Gemini CLI 调用 mcp__trustabl__scan。将以下内容添加到 ~/.gemini/settings.json：

{
  "mcpServers": {
    "trustabl": {
      "command": "trustabl",
      "args": ["mcp"]
    }
  }
}

工作原理。 Gemini CLI 会话启动时，扩展会注入 GEMINI.md 作为上下文，其中通过 @ 导入包含完整的 trustabl-scan 和 trustabl-enrich 技能内容。Gemini 随后会像处理任何已加载的上下文一样处理这些技能：在你编写 或修改 Agent、工具或 MCP 服务代码后运行扫描，并提供通过 trustabl-enrich 应用发现结果的选项。MCP 工具名为 mcp__trustabl__scan——与 Claude Code 中的名称相同。

稍后更新扩展：

gemini extensions update trustabl

OpenAI Codex 插件（生成时自审）

Trustabl 随附 OpenAI Codex 插件，位于 .codex-plugin/， 其中包含相同的两个技能。

先决条件。 请先安装 Trustabl 二进制文件：

# macOS / Linux
brew install trustabl/tap/trustabl

# Windows
scoop bucket add trustabl https://github.com/trustabl/scoop-bucket
scoop install trustabl

安装插件。 在 Codex CLI 中，打开插件搜索界面并 搜索 trustabl：

/plugins

搜索 trustabl 并选择 Install Plugin。在 Codex App 中，转到侧边栏中的 Plugins，在 Security 类别下找到 Trustabl，然后 点击 +。

注册 MCP 服务，以便 Codex 调用 mcp__trustabl__scan。将以下内容添加到 ~/.codex/config.toml：

[mcp_servers.trustabl]
command = "trustabl"
args = ["mcp"]

工作原理。 Codex 会读取 .codex-plugin/plugin.json， 其中指定 "skills": "./skills/"。Codex 会自动从该目录加载 trustabl-scan 和 trustabl-enrich 技能——无需显式调用。编写或修改 Agent、工具 或 MCP 服务代码时会触发技能，Codex 会通过 trustabl-enrich 应用发现结果。MCP 工具名为 mcp__trustabl__scan——与 Claude Code 和 Gemini CLI 中的名称相同。

若要在 Codex 中启用子 Agent 委派（trustabl-enrich 用它并行 编辑文件），请在 ~/.codex/config.toml 中设置 multi_agent = true。

“规则版本比此 Trustabl 构建版本更新”

Trustabl 会向前兼容地加载规则。如果解析出的规则包面向的规则架构版本比你的二进制文件所理解的版本更新，扫描仍会运行：它会评估此构建版本能够理解的所有规则，并跳过其余规则，同时在标准错误输出中发出警告（并将跳过的规则 ID 记录在 ScanResult.RulesSkipped 中）：

warning: the rules target schema version 13 but this Trustabl build supports up to 12; 2 rule(s) newer than this build were skipped. Upgrade Trustabl to evaluate them.

对于任何引用了此构建版本无法理解的 scope、applies_to 值或谓词的单条规则，也会执行同样的跳过处理——该规则会被丢弃，但同组的其他规则仍会运行，因此较新的规则版本永远不会迫使你同步升级二进制文件。每次跳过也会在报告本身中显示为一条 META-005 信息级发现（“N 条规则需要更新版本的 Trustabl 引擎”），因此扫描结果不完整时绝不会被误认为没有问题。对于此构建版本能够理解的格式错误规则（字段缺失、值无效），不会向前跳过——加载仍会硬性失败，因此真正的编写错误不会被悄悄丢弃。

要评估被跳过的规则，请将 Trustabl 升级到其 SupportedSchemaVersion（参见 internal/rules/schema_version.go）涵盖该规则包的构建版本。如果你可以接受仅运行部分规则，则无需采取任何操作。

只有在没有可用规则时，扫描才会失败（退出代码 2）：

• “所有规则都要求更新版本的引擎架构”——你的构建版本无法处理任何规则，因此没有可运行的规则。请升级 Trustabl，或固定到你的构建版本能够完全理解的较旧规则分支/标签（--rules-ref 只解析分支和标签，不解析原始提交 SHA，因此兼容的引用必须已经存在）：

  trustabl scan ./repo --rules-ref <branch-or-tag>
  

• “没有可用的规则清单”——规则包的 manifest.yaml 缺失、无法解析，或声明了非正数版本（规则包损坏或截断）。请运行 trustabl rules pull 以刷新。

• “未找到可用规则”——缓存中没有规则，也无法获取规则（离线且缓存为空）。请在联网时运行 trustabl rules pull。

代码所在位置

流水线节点	代码路径
导入器	internal/ingestion/importer.go
规范化器（重建）	internal/ingestion/normalizer.go
发现（Python AST + markdown/JSON）	internal/analysis/discovery.go、agents.go、hosted_tools.go、mcp_servers.go、adk_agents.go（Python AST）；subagents.go、markdown_agents.go、skills.go、slash_commands.go（markdown frontmatter）；plugins.go、claude_settings.go（JSON）
TypeScript 发现	internal/analysis/ts_discovery.go、ts_agents.go、ts_mcp_servers.go、ts_handler_facts.go、ts_openai_tools.go、ts_openai_agents.go、ts_openai_hosted_tools.go、ts_openai_mcp_servers.go、ts_openai_guardrails.go、ts_openai_sessions.go、ts_adk_tools.go、ts_adk_agents.go、ts_adk_hosted_tools.go、astutil/ts.go
检测器运行时	internal/analysis/detectors/
规则源	internal/rulesource/（git 获取 + 缓存 + 架构版本门控）
检测器规则	外部 agent-reliability-rules 仓库（测试：testdata/rules-fixture/）
规则引擎	internal/rules/{schema,loader,evaluator,predicates,rule_detector}.go
评分引擎	internal/analysis/scoring.go
报告渲染器	internal/review/diff.go（人工可读）、internal/sarif/render.go（SARIF）、cmd/trustabl 中的 JSON marshal
LLM 配置	internal/llm/（密钥存储 · 遮蔽 · 验证）

规则包存放在独立的 agent-reliability-rules git 仓库中（按 {claude_sdk,openai_sdk,google_adk,mcp}/ 分组），在扫描时解析， 而不是嵌入二进制文件。命名约定：Claude Agent SDK 规则使用 CSDK-NNN（CSDK-0xx 为工具范围，CSDK-1xx 为 Agent + 子 Agent 范围）， OpenAI Agents SDK 规则使用 OAI-NNN，Google ADK 规则使用 ADK-NNN， 专用 MCP 工具范围规则包使用 MCP-NNN。 请参阅 ARCHITECTURE.md § 2 — steps 3–4，了解 已发布的规则表；另请参阅 COVERAGE.md，了解各 SDK 的识别 详情。

测试

testdata/corpus/ 存放真实世界的 Agent 代码（Claude SDK 演示、OpenAI Agents SDK 演示、Google ADK 演示、一个 TS Claude SDK 样例）——这是语料库，而非 受控样例，因此编写良好的 Agent 不会触发大多数规则，这是正确的。请参阅 testdata/corpus/PROVENANCE.md，了解各示例的上游来源和许可证。每条规则触发或不触发的 正确性由 internal/rules/policies_test.go 验证；端到端 扫描测试 internal/scanner/scanner_test.go 仅断言扫描器 不会因真实世界输入而崩溃。带标签的 20–40 个真实 Agent 仓库 语料库是检测质量的目标（请参阅 ARCHITECTURE.md § 10）； 当前测试用于回归覆盖，而非检测质量 衡量。

隐私与遥测

Trustabl 可选择收集匿名使用数据——扫描了哪些 SDK、扫描时长、触发了哪些规则——以指导产品方向。绝不会发送源代码、文件路径、仓库名称或发现详情。遥测功能默认关闭；首次进行交互式扫描时，Trustabl 会询问你要选择哪个级别。

发生 panic 时，Trustabl 会将经过清理的崩溃报告写入 ~/.config/trustabl/crash-<timestamp>.log，并且仅在交互式终端中提供匿名发送或打开预先填写内容的 GitHub 问题的选项——否则不会传输任何内容。不会自动发送：默认始终保持静默，是否发送由你针对每次崩溃明确选择。报告包含 panic 消息（尽力对常见格式的密钥进行脱敏）和堆栈帧；不包含源代码、文件内容或参数值。

有三个级别可供选择：

• 禁用 — 不发送任何数据（默认）
• 最少 — 仅发送 CLI 版本和扫描结果
• 完整 — 匿名使用统计

trustabl telemetry off          # disable
trustabl telemetry minimal      # version and outcome only
trustabl telemetry full         # full anonymous usage stats
export TRUSTABL_TELEMETRY=0     # or disable for the current shell session
trustabl telemetry status       # show current level and its source

完整事件架构——每个事件名称和每个属性的原文——请参阅 TELEMETRY.md（以及 trustabl.ai/docs/telemetry）。该页面会与代码保持同步；文档过时会被视为缺陷。

常见问题

什么是 Agent Reliability Analyzer？ 它是 Trustabl 推出的开源确定性扫描器，可在生产环境部署前，发现并修复 AI Agent 代码中的 Agent 可靠性问题，支持九种 Agent SDK 和七种语言。

如何在生产环境部署前测试 AI Agent 的可靠性？ 在本地或 CI 中运行 trustabl scan ./your-agent-repo。它会依据 Agent 可靠性规则检查工具、Agent、子 Agent、技能和 MCP 服务；如果发现中等级或更高级别的问题，则以非零状态码退出，从而在需要时使 CI 任务失败。

它能取代 LangSmith、Langfuse、Braintrust 或 Arize 吗？ 不能。这些工具会在运行时观察和评估 Agent；Agent Reliability Analyzer 则会在代码运行前发现缺陷。可搭配使用。

它会把我的代码发送到其他地方吗？ 不会。扫描在本地进行且结果确定——不使用大模型，也不上传代码。默认情况下，它会下载最新规则和漏洞数据；使用 --no-rules-update 时，则会从本地缓存完全离线运行。trustabl enrich 为可选功能，使用你自己的大模型密钥。遥测功能默认关闭。

它支持哪些 Agent 框架？ 支持九种 SDK，包括 Claude Agent SDK、OpenAI Agents SDK、Google ADK、LangChain / LangGraph、CrewAI、AutoGen / AG2 和 Pydantic AI。完整列表请参阅：COVERAGE.md。

Trustabl 开源 Agent 可靠性工具集的一部分

Agent Reliability Analyzer 是 Trustabl 推出的开源 Agent 可靠性工具集中的一部分：

• agent-reliability-rules — Analyzer 加载的确定性 Agent 可靠性检测规则
• trustabl-action — 将 Analyzer 作为 GitHub Action 运行
• agent-opentelemetry-rules — 面向可观测性平台的 Agent 专用 OpenTelemetry 规则
• trustabl-aws — 面向 AWS CodePipeline 和 CodeCatalyst 的 Analyzer

这些检查实现了 Agent Reliability Engineering (ARE) 中的理念。ARE 是一门开放学科，致力于构建可靠、可治理的 AI Agent。Trustabl 与 ARE 的作者有关联。

社区

加入 Trustabl Discord，提问、分享反馈并关注开发进展。

许可证

Apache-2.0。请参阅 LICENSE。