elizaOS
构建、运行并扩展自主 AI 智能体的开源 TypeScript 系统。
工作流使用只读默认权限、环境级凭据、固定提交的 Actions、精确 SHA/分支/部署身份校验和显式生产审批边界；Telegram 边缘启用要求人工 dispatch、精确源版本和健康证明，并在未证明成功时回滚。安全材料还展示私密漏洞报告、密钥不回读、敏感计划加密与清除、凭据响应脱敏及秘密泄漏审计，因此最小权限、敏感数据处理、外部副作用和回滚证据很强。扣分在于：用户确认主要由少数高风险工作流和钱包的概括性“approval boundaries”体现，未展示所有代理动作的统一确认策略；数据流仅有架构级说明和局部测试，未形成完整的插件/云端/模型提供商数据清单；依赖审计虽有门禁和维护流程，但未提供本修订的审计结果或完整供应链策略；归属可见于版权、团队邮箱及组织链接，但发布者身份按题设仍未验证。
README、清单、工作流说明和路由测试在运行方式、能力路由、错误语义与验证入口上相互一致。测试明确覆盖真实未找到、无凭据、无效提供商、能力不可用、健康状态和不伪造成功等情况，工作流也提供精确且可操作的失败信息，因此一致性与失败消息充分。依赖版本大量固定或约束，Node 与 Bun 版本明确，也有依赖和发布图审计；但大型单体仓库依赖许多外部模型、CLI、云服务及插件，且未提供离线依赖镜像或本修订的可用性报告，故依赖可用性未满分。
材料清楚区分终端用户、代理/插件开发者、贡献者和整机用户，并覆盖 Web、桌面、移动、云、自托管及本地推理场景。能力受操作系统、插件、权限、硬件和提供商约束的边界被明确陈述，账户 API 还暴露运行资格与不可用原因。工作流使用手动、分支、路径、标签和环境触发，且危险部署有精确目标校验，触发精度充分。固定工具版本、Windows 指南、本地/云/直接提供商路由和轻量安装选项使环境适配证据完整。
顶层 README 提供起点表、仓库地图、组件职责、常用命令和贡献/安全入口，信息架构与安装说明完整；MIT 正文与元数据一致，可满分。示例涵盖源码运行、CLI 脚手架和测试命令，但所给材料没有 FAQ 或完整端到端用户示例，因此该项扣分。限制条件有所披露，却分散在能力可用性、安全范围和外部仓库说明中，未见集中限制清单。根版本和 latest/beta 支持策略明确，但未提供变更日志或迁移记录；同时 beta、alpha、未限定范围与多包命名并存，命名稳定性只能给中等分。维护渠道、贡献流程、SLA 和发布职责清楚，但发布者未经登记验证，且未给出明确个人维护者/治理与长期接替机制。
该项目把运行时、代理宿主、UI、CLI、云服务、本地推理、原生桥接和插件体系组合为可直接使用或嵌入的输出，并提供清晰的启动、构建和部署入口，产物可用性与相对普通聊天封装的增量价值很高。能力路由、本地离线选择及轻量安装可降低部分成本。不过大型 monorepo、硬件模型资源、外部提供商、云部署与复杂验证矩阵带来明显运维和资源成本，材料未给出量化性能、资源占用或费用比较，因此成本收益不满分。
主要声明能追溯到具体包、脚本、工作流、测试和策略文件；README 的运行、验证、安全及能力边界受到 package.json、工作流说明和测试的交叉支持。测试名称、注释和断言清楚区分目标行为、不可用状态及错误结果，README 也用“取决于”“可选”“当配置时”等措辞避免把条件性能力写成既成事实。由于这是未执行的静态审查，不能据此证明测试通过或部署状态，但该限制属于置信度而非这些静态可核验标准的扣分项。
- 这是未执行代码、测试或依赖审计的静态审查；脚本和测试的存在不能证明它们在该修订上通过。
- 该系统可连接模型提供商、云服务、消息平台、浏览器、设备接口和钱包；部署前应逐插件核查权限、数据去向、保留策略及人工批准行为。
- 安装会运行较长的 postinstall 链并同步运行时制品；应在隔离环境中审查锁文件、补丁和安装脚本后再执行。
- 安全支持仅覆盖当前 latest 与 beta 小版本，第三方插件不在其范围内；旧版本及外部插件需要单独的风险管理。
- 高风险工作流展示了良好保护，但不能据此推断所有代理动作都具备同等确认、回滚或最小权限控制。
这个 Agent 能做什么，适合哪些场景？
elizaOS 是一个模型无关的开源 TypeScript 框架和产品栈，用于构建与运行自主 AI 智能体。该单体仓库包含核心运行时、Eliza 用户应用、项目与插件 CLI、云服务、原生桥接层、共享 React UI 和第一方插件。其核心 @elizaos/core 提供 AgentRuntime、消息循环、记忆与状态原语以及插件契约，@elizaos/agent 则围绕运行时组装独立智能体和 HTTP 后端。Eliza 面向 Web、桌面和移动端，可通过插件提供聊天、语音、知识、文档、消息连接、个人助理、自动化及钱包操作等能力。模型能力可以按需路由到本地推理、直接模型提供商或可选的 Eliza Cloud；可启动的 Linux 与 Android 发行版则由独立的 elizaOS/os 仓库维护。它适合需要可嵌入运行时、插件扩展机制和多种部署路径的团队，但实际功能取决于操作系统、已安装插件、权限以及所配置的模型或服务。
消息进入 AgentRuntime 后，由核心消息循环结合记忆和状态原语处理，并调用插件注册的 actions、providers、evaluators、services、model handlers、routes、events 或 app views。@elizaos/agent 可将该运行时封装成独立智能体及 HTTP 后端，@elizaos/app-core 负责应用托管、API 和平台编排，@elizaos/ui 提供共享 React 界面。Eliza 应用可执行聊天、语音、记忆、知识和文档流程，也可通过相应插件连接消息与工作空间服务，管理日历、提醒、收件箱、目标和健康信息，或进行浏览器与桌面自动化。原生桥接层可在获得权限后访问摄像头、电话、消息、联系人和位置；钱包功能支持带审批边界的非托管 EVM 与 Solana 操作。本地推理插件 @elizaos/plugin-local-inference 会检测硬件并路由模型，所需资源下载完成后，符合条件的文本、嵌入、语音、视觉或图像生成操作可以离线运行；其他能力可转交直接提供商或 Eliza Cloud。
- TypeScript 团队需要以 @elizaos/core 嵌入 AgentRuntime，并围绕自有应用实现消息循环、记忆、状态和模型调用。
- 插件开发者需要用 elizaos CLI 创建可复用能力包，为运行时注册动作、服务、路由、事件、测试或应用视图。
- 产品团队需要同时交付 Web、桌面和移动端智能体界面，并复用 @elizaos/app-core 与 @elizaos/ui。
- 希望降低持续联网依赖的团队，可在受支持硬件上下载 Eliza-1 资源，通过 @elizaos/plugin-local-inference 执行符合条件的本地任务。
- 个人助理产品开发者需要通过插件组合聊天、文档、日历、提醒、收件箱、消息连接和设备能力。
- 需要自托管与托管选项并存的团队，可选择本地运行时、直接模型提供商配置，或采用 Eliza Cloud 的认证、模型路由和部署服务。
这个 Agent 有哪些优点和局限？
- 核心运行时明确采用模型无关设计，可在本地推理、直接提供商和 Eliza Cloud 之间路由不同模型能力。
- 插件契约覆盖 actions、providers、evaluators、services、model handlers、routes、events、tests 和 app views，扩展面较完整。
- 同一仓库提供运行时、HTTP 智能体后端、共享应用托管层、React UI、CLI、云服务和原生桥接，适合构建完整产品而不只是单一聊天机器人。
- 本地推理路径包含硬件检测和模型路由；资源下载后，受支持操作可以在无网络环境下执行。
- 提供 build、verify、单元与集成测试、端到端测试以及云端模拟命令，开发验证路径清晰。
- 仓库规模较大，bun install 会准备子模块、补丁和运行时资源；大型资源包可能增加下载、存储和初始化成本。
- 功能可用性受操作系统、插件、权限、硬件以及模型或服务提供商配置影响，不能假设所有能力开箱即用。
- 本地推理不会强制运行在不支持的硬件上，2B、4B、9B 和 27B 模型层级也意味着设备适配与资源规划成本。
- 可启动的 Linux 和 Android 系统发行版位于另一个 elizaOS/os 仓库，整机部署需要跨仓库维护。
- CLI 来自 beta 分支并以 elizaos@beta 发布，采用时需要考虑接口或脚手架变化风险。
- 钱包、摄像头、联系人、位置等敏感能力需要审批边界或系统权限，部署方必须单独设计授权和安全策略。
如何安装或部署这个 Agent？
先安装仓库 package.json 中锁定的 Bun 与 Node.js 版本，并确保 Git 可用。执行：
git clone --filter=blob:none https://github.com/elizaOS/eliza.git
cd eliza
bun install
bun run devbun install 会准备子模块、补丁和运行时资源；若希望跳过大型资源包，可改用 bun run install:light。源码没有给出固定的模型凭据名称；需要联网模型或服务时，应按所选提供商或 Eliza Cloud 的配置要求提供凭据。若只需 CLI，可执行 bun add --global elizaos@beta。
如何使用这个 Agent？
创建可部署项目：
elizaos create my-project --template project创建可复用插件：
elizaos create plugin-example --template plugin若直接嵌入运行时，则在 TypeScript 项目中导入 @elizaos/core。仓库开发可用 bun run build 构建工作区，bun run verify 执行包一致性、依赖、类型、代码检查和审计门禁，bun run test 运行单元与集成测试，bun run test:e2e 运行端到端测试。需要本地模拟云端栈时运行 bun run cloud:mock。具体智能体首次可用的模型和服务配置取决于选用的本地推理、直接提供商或 Eliza Cloud 路径，源材料未给出统一配置命令。
这个 Agent 与同类方案有什么区别？
与可选的 Eliza Cloud 路径相比，本地运行时和直接模型提供商配置仍是一等选择：前者提供账户、认证、托管模型路由、应用与智能体部署、远程连接及跨设备服务；后两者提供更直接的自托管与提供商控制。对于整机系统，当前单体仓库负责 Eliza 应用外壳和原生运行时桥接，而独立的 elizaOS/os 仓库负责可启动 Linux、AOSP、安装器、发布清单和操作系统工具链。