Agentlas OS
将可移植的单体或团队 Agent 打包、路由并在本地模型宿主中执行。
按维度查看评分与理由
证据显示有权限控制（如沙箱、anti-scope、caller-gating）和用户确认（如import作为proposal），但缺乏具体实现细节和验证。数据流透明度有描述（如redacted WorkOrder、local-first），但未提供实际日志或审计示例。敏感数据处理有提及（如不存储credentials），但未展示具体机制。依赖安全未提及，无依赖清单或漏洞扫描。外部影响有描述（如Telegram连接、发布到Hub），但未明确权限边界。回滚有提及（如rollback coverage），但未提供具体实现。来源归属有提及（如digests、receipts），但未提供验证方法。
自洽性较好，README中多处描述一致（如命令别名、安装方法）。依赖可用性未明确，未列出依赖清单或版本。失败消息有提及（如verified/unverified/blocked状态），但未提供具体错误处理示例。
目标受众明确（开发者、企业），场景多样（客服、市场报告等）。能力边界有描述（如anti-scope、triggers）。触发精度有描述（如ambiguity gates、anti-triggers）。环境适配有描述（支持多种LLM和本地模型）。
信息架构清晰，有目录结构和文档索引。安装说明详细，提供多种方法。命名稳定，有别名兼容。示例和FAQ有提供（如命令示例）。已知限制提及较少，仅提到一些注意事项。许可证明确为Apache-2.0。版本和变更日志有提及（如v1.1.0），但未提供详细变更日志。维护责任未明确，未提及贡献指南或维护者。
输出可用性有描述（如verified/unverified状态、work brief），但未提供实际输出示例。边际价值有描述（如避免重复配置、模型中立），但未量化。成本效益未明确，未提供性能或资源消耗数据。
声明可追溯性一般，部分声明有文档链接，但未提供具体证据。跨来源佐证不足，主要依赖README自身。事实与推断分离不明确，未区分哪些是已验证事实，哪些是设计意图。
- 依赖安全未提及，建议检查依赖清单和漏洞扫描。
- 安装脚本通过curl管道执行，存在供应链风险，建议审查脚本内容。
- 发布者身份未验证，需谨慎对待。
这个 Agent 能做什么，适合哪些场景？
Agentlas OS 是以 Hephaestus 为核心的本地优先 Agent 运行与打包系统，而不是托管式模型服务。它将自然语言需求编译为带有角色、输入输出契约、路由卡、记忆边界和验证脚本的单 Agent 或多 Agent 包。外部宿主可通过统一命令面使用该系统；仓库明确提供 Claude Code、Codex、Gemini CLI、Antigravity、Cursor 等适配路径。Network 2.0 在 Local、私有 Agent Cloud 和公开 Hub 三个精确范围内检索并校验选定包，Stormbreaker 则以验证、有限修复和最终门控管理执行。实际工作仍由当前主机上的所选模型、文件、工具、凭据和权限完成；Cloud 只存储和恢复包，不在服务器端代为执行模型任务。
/agentlas build 将请求交给单 Agent、团队或工作区打包构建器，生成包含 package-contract.json、contracts/intake.schema.json、contracts/output.schema.json、.agentlas/brief.json 等契约的包，并可用 scripts/verify-generated-package.sh <folder> 校验。/agentlas network 将任务形成 WorkOrder，在 local、cloud、hub 范围获得候选内容，由宿主 LLM 编写 Selection，核心再验证治理、身份、基数和图完整性，并校验所选不可变发布包的摘要。Stormbreaker 按“范围锁定、分解、并行工作包、契约验证、有限修复、最终门控”执行，记录本地 run journal，并报告 verified、unverified 或 blocked。bin/ontology 可将本地语料摄入 SQLite，使用 FTS5、倒数排名融合和 GraphRAG 查询；A2A 导入、导出与调用通过 agentlas-cloud ao a2a 和 agentlas-cloud route 提供边界控制。
- 使用 Claude Code 或 Codex 的工程团队，需要把市场研究、写作、QA 与发布拆分给明确角色，并保留交接和验证记录。
- 需要把客户支持、审查或内部工作方法做成可迁移包的个人开发者，希望更换电脑或支持的模型宿主后从私有 Agent Cloud 恢复该包。
- 维护本地文档库的团队，需要用
bin/ontology ingest和本地 SQLite/FTS5/GraphRAG 检索项目知识，而不将原始文档发送到云端钩子。 - 希望从公开 Hub 借用可用专长包、但不希望复制发布者私有源工作或把本地私有文件交给对方 Agent 的使用者。
- 需要把 Agent 输出限制为可验证结果的交付负责人，可借助 Stormbreaker 的契约检查、有限修复和明确完成状态。
这个 Agent 有哪些优点和局限？
- 以契约化包而非单一角色提示组织 Agent：输入输出 JSON Schema、路由卡、记忆映射和验证脚本都有明确位置。
- 执行与模型提供商分离：仓库记录了 Claude Code、Codex、Gemini CLI、Antigravity、Cursor 及兼容本地/API 宿主的适配路径。
- Network 2.0 将 Local、私有 Cloud 与公开 Hub 设为明确范围，并在执行前验证所选发布包的内容与摘要。
- Stormbreaker 使用本地 journal、契约验证、有限修复和 verified/unverified/blocked 状态，适合需要可审计完成条件的工作。
- 安装和运行依赖本地 shell、Git、宿主模型账户或 API 密钥；并非开箱即用的托管模型服务。
- 跨机器迁移只恢复 Agent 包；凭据、本地文件和机器权限必须在每台电脑单独配置。
- Cloud 与 Hub 的登录、额度、授权或匹配不佳会触发回退或边界提示，不能保证始终可用。
- 功能面较广，采用时需理解包契约、宿主适配器、路由范围与本地权限边界；README 未给出完整的托管服务定价信息。
如何安装或部署这个 Agent？
在操作系统终端运行：xcode-select --install（尚未安装命令行工具时）、git --version，然后运行：curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | bash。安装器会安装 ~/.agentlas/runtime/current/bin/hephaestus 并注册支持宿主的命令适配器。若要让普通提示经过全局路由，可运行 hephaestus global install；该命令会修改 Codex、Claude Code 与 Gemini/Antigravity 的指定配置文件并创建带时间戳的备份。使用 Cloud 前须在已支持且已安装的 Agentlas OS 宿主中登录；本地执行仍使用你自行配置的模型账户或 API 密钥。
如何使用这个 Agent？
在外部 LLM 宿主中，可先运行 /agentlas search find agents for a market report workflow 查找可用包；构建新包可运行 /agentlas build create a customer support agent for Shopify refunds；需要联合范围调度时使用 /agentlas network split this launch plan into research, copy, QA, and release agents。只使用本机、私有 Cloud 或公开 Hub 包时，分别使用 /agentlas local、/agentlas cloud 或 /agentlas hub。在 Codex 0.117+ 中，使用插件技能，例如 $hephaestus-network <request> 或 $hephaestus-build <request>，而非已移除的自定义 /prompts:* 命令。
这个 Agent 与同类方案有什么区别？
仓库将 CrewAI、LangChain 和厂商 Agent SDK 定位为单进程内编写自定义逻辑的库；Agentlas/Hephaestus 则定位为负责规格化、打包、路由、运行、审计和跨工作区迁移的运行底座。它也明确区分于仅靠角色提示、工具列表和单次会话的 Claude 子 Agent 或自定义 Agent。
常见问题
它会在 Agentlas Cloud 上替我运行模型吗？
包迁移到另一台电脑后，密钥和文件会一并迁移吗？
任务无法验证时会发生什么？
是否必须使用公开 Hub？
network 才是三者的联合范围。