TrueForge
为大模型补齐工具、沙箱、会话与审批能力的开源智能体运行层。
工作流普遍使用空的顶层权限和按任务限定的 contents、id-token、pull-requests 权限，README 也描述沙箱隔离、按需创建和人工工具审批，因此最小权限、数据流和外部影响有实质但不完整的支持。认证测试覆盖 401、会话探测、带凭据登出及失败处理，且本地模式明确警告无默认登录、只能绑定本机；但“密钥留在 harness 中”和人工检查点主要是声明，未提供底层授权、密钥存储或审批绕过测试。依赖管理固定 pnpm 版本并带完整性摘要，部分 Actions 固定主版本，但可复用构建工作流引用可变的 @main，下载的 yq 未校验摘要，故依赖安全仅为薄弱支持。没有展示代理工具副作用的统一撤销、事务或恢复机制，rollback 为 0。许可证、版权主体、安全邮箱、创始人邮箱和私密漏洞报告路径均清楚，因此来源归属充分；注册表未验证只表示身份未知，不作为额外惩罚。
README、package 脚本、认证测试和发布工作流对产品形态、Node 要求、本地/托管模式及认证路径基本一致。Node、pnpm、SQLite、Postgres、Redis、Docker、Helm 和外部模型/沙箱依赖均有一定说明，但完整安装细节主要位于未提供的外部文档，且发布构建依赖可变的外部工作流。测试表明部分认证和登出失败会产生明确状态或错误，发布脚本也验证版本并输出错误；然而证据只覆盖前端认证和发布路径，未证明代理循环、模型、MCP、沙箱及会话故障都能提供同等质量的消息，因此三项均未给满分。
个人试用、团队托管、多副本、API 自动化、嵌入式 UI 等受众和场景划分清晰，本地与托管的基础设施对照充分，环境适配获得满分。项目支持多模型提供商、可配置 MCP、技能、沙箱及多种部署形态。边界方面明确说明本地模式不适合生产或公网，并将未来沙箱提供商标为规划中，但没有展示资源限额、工具策略或不支持能力的完整清单。按需沙箱、延迟工具加载和人工审批有助于触发精度，但主要来自 README 描述，缺少相应实现或测试证据，故未给满分。
README 的产品概述、能力、架构、模式、文档索引、贡献、安全联系和许可证结构清楚，包名及 trueforge、trueforge-sdk、trueforge-ui、trueforge-core 的命名一致。Node 要求和 npx 入口明确，但仓库内安装步骤很短，关键步骤转交外部 Quickstart，因此 install_notes 为 2。提供功能列表和架构表，但没有实际的端到端代码示例或 FAQ，examples_and_faq 仅为 1。本地模式风险和最新版本支持政策构成有用但不完整的限制说明。MIT 正文完整。Changesets、版本脚本、语义版本校验及发布 PR 流程支持版本管理，但未提供变更日志内容，故版本/变更日志不满分。贡献路径、安全响应时限、联系邮箱和维护者发布流程使维护责任清晰，虽发布者企业注册身份仍属未知。
产品输出可通过聊天 UI、HTTP API、TypeScript SDK 和嵌入式 UI 使用，并支持本地及托管部署，因此输出可用性证据充分。与自行拼装流式传输、持久化、工具、审批、沙箱和 UI 相比，功能组合显示明确的边际价值，但提供的源码片段没有展示完整代理循环实现。成本与准确率优势只有 README 的基准测试声明和未展开的 benchmark 目录引用；本地/托管基础设施权衡有所说明，但缺少所引用结果、方法和数字，故 marginal_value 为 2、cost_benefit 为 1。
若干主张可追溯到 package 脚本、权限受限的工作流、认证测试、安全政策和许可证，且 README 关于认证、部署和发布的部分描述得到其他文件交叉支持。不过关键代理能力、沙箱隔离、密钥保护、人工审批及基准优势没有由所给实现文件或测试直接佐证。README 将尚未支持的沙箱提供商明确标为计划中，这是良好分离；但“相同准确率、更低成本”等营销结论在提供材料中未与可核查结果分开呈现，所以事实与推断分离仅为薄弱支持。
- 本地模式默认无登录；必须保持仅 localhost 可访问，团队或公网部署应使用带 OIDC 的托管模式。
- 所给证据未展示模型凭据、MCP 认证头、OAuth 令牌及沙箱密钥的存储、加密、脱敏和生命周期实现。
- 代理工具副作用没有通用撤销或恢复证据；启用可写工具前应逐项配置审批、权限范围和外部系统恢复方案。
- 构建流程引用 truefoundry/github-workflows-public 的可变 main 分支，并下载未校验摘要的 yq，供应链固定性有限。
- “相同准确率、更低成本”的基准结论无法从提供文件核实，不应据此作出采购或生产容量决策。
- 本评估仅为静态审阅，未执行测试、安装、代理任务、沙箱逃逸检查或依赖漏洞扫描。
这个 Agent 能做什么，适合哪些场景？
TrueForge 是一个开源智能体执行框架，负责运行模型调用、MCP 工具、技能、沙箱、审批、上下文管理和会话状态组成的执行循环。它提供内置聊天界面、HTTP API、TypeScript SDK `@truefoundry/trueforge-sdk`，以及可嵌入的 `@truefoundry/trueforge-ui`。系统可以连接 OpenAI、Anthropic、Google Gemini、其他目录内提供商和兼容 OpenAI 的端点，并支持带请求头认证或 OAuth 的远程 MCP 服务。部署边界分为单进程加 SQLite 的本地模式，以及使用 Postgres、Redis并通过 Docker Compose 或 Helm 运行的托管模式。它适合希望采用现成运行时而非自行拼装流式传输、持久会话、工具授权、隔离执行和聊天界面的开发团队。
管理员先从可定制的 YAML 目录配置模型、MCP 服务器、Git 支持的 SKILL.md 技能和沙箱，智能体再从这些已连接资源中选择所需能力。执行期间，TrueForge 管理模型调用和智能体循环，调用远程 MCP 工具，按需加载技能，并在需要时配置 Daytona 隔离沙箱执行代码或文件操作。它还能暂停敏感工具操作以等待人工批准、向用户提问，并在聊天中生成交互式界面。上下文层支持子智能体、延迟加载工具、Code Mode、大结果卸载和压缩；会话及轮次则可通过聊天界面或 HTTP API 操作，并由 TypeScript SDK 处理 sessions、turns 和 events。最终产出通过内置聊天界面、嵌入式 UI SDK 或 API 事件流交付。
- 个人开发者希望在自己的电脑上试验带持久会话、工具调用和聊天界面的智能体时，可使用单进程 SQLite 本地模式。
- 平台工程团队需要为多个内部智能体统一管理模型、MCP 服务、技能、沙箱和审批策略时，可把 TrueForge 部署为共享运行层。
- TypeScript 团队已有自己的产品界面，但需要通过 API 创建会话、提交轮次并消费事件时，可采用
@truefoundry/trueforge-sdk。 - 产品团队希望把现成的智能体聊天体验嵌入应用时，可使用
@truefoundry/trueforge-ui，而不必重新实现完整聊天界面。 - 需要执行代码或文件任务且不希望把秘密直接交给执行环境的团队，可采用按需配置的 Daytona 沙箱。
- 需要人工控制高风险操作的团队，可利用工具审批、用户提问和聊天内 Generative UI 设置检查点。
这个 Agent 有哪些优点和局限？
- 将模型调用、流式交互、会话持久化、MCP、技能、沙箱、人工审批和上下文管理集中在同一运行层。
- 同时提供内置聊天界面、HTTP API、TypeScript SDK 和可嵌入 UI SDK，既能直接使用，也能集成到现有产品。
- 明确支持 OpenAI、Anthropic、Google Gemini、其他目录提供商及兼容 OpenAI 的端点，降低单一模型提供商锁定。
- 可从单进程 SQLite 本地模式扩展到 Postgres、Redis、Docker Compose 或 Helm 托管模式。
- 具备子智能体、延迟工具加载、大结果卸载和上下文压缩等面向长流程执行的上下文工程能力。
- 沙箱按需配置，秘密保留在运行框架中，并可在工具执行前加入人工检查点。
- 本地模式默认没有登录，只应绑定 localhost；项目明确表示它不适合生产或互联网暴露场景。
- 生产部署需要 Postgres 和 Redis，并引入 Docker Compose 或 Helm 的运维成本。
- 当前明确记录的隔离执行提供商是 Daytona，其他沙箱提供商仍处于计划阶段。
- 源材料没有提供完整安装配置、SDK 示例、HTTP 首次调用、端口或凭据环境变量，单靠所给信息无法完成无歧义的自动化部署。
- 使用远程模型和 MCP 服务需要网络访问，并可能需要分别管理请求头凭据或 OAuth 授权。
- README 仅声称基准测试在相同任务、工具和模型下达到相同准确率且成本更低，但没有在所给材料中列出具体测量值。
如何安装或部署这个 Agent？
本地模式要求 Node.js >= 22.14。在终端执行 npx @truefoundry/trueforge，该模式以单进程运行并使用 SQLite，无需额外基础设施。启动后需要连接至少一个模型，并按需配置 MCP 服务、技能和沙箱，然后依照 https://trueforge.dev/quickstart 创建首个可复用智能体。模型提供商凭据以及远程 MCP 的请求头认证或 OAuth 信息取决于所连接服务；源材料没有给出具体环境变量名。共享或生产环境应采用托管模式，其依赖 Postgres 和 Redis，并支持 Docker Compose 或 Helm，但源材料没有提供可直接复制的完整部署命令。
如何使用这个 Agent？
最小可验证流程是先运行 npx @truefoundry/trueforge，在初始设置中连接受支持的模型，并选择需要的 MCP 服务、SKILL.md 技能和沙箱。随后创建智能体并从内置聊天界面发起会话；TrueForge 会运行模型与工具循环、保存会话状态，并在受控操作前请求批准。程序化集成可使用 @truefoundry/trueforge-sdk 操作 sessions、turns 和 events，或直接调用 HTTP API；前端嵌入可使用 @truefoundry/trueforge-ui。源材料没有给出 SDK 初始化代码、HTTP 请求示例、端口、配置文件字段或凭据变量，因此无法据此提供更具体且可靠的首次 API 调用。
这个 Agent 与同类方案有什么区别？
项目将 TrueForge 与 Claude Managed Agents 和 deepagents 放在相同任务、工具及模型条件下比较，并声称在相同准确率下成本更低；复现实验位于仓库的 benchmark/。所给材料没有包含具体分数、成本数值或实验细节，因此不能进一步量化差距。