自动化与运维 workflow-automationmulti-agent-orchestrationautonomous-developmentcodex-cliself-hostingruntime-observabilityfailure-recovery

Auto Company 自主 AI 公司

在个人电脑上持续组织多角色 AI 团队完成产品研发与运营。

FollowAgents 评估 · FARS-2.1
谨慎使用
70/ 100 五分制 3.5 / 5
1 2 3 4 5 6
按维度查看评分与理由
1信任安全12 / 29 · 2.1/5

文档明确披露本地日志、看板、模型用量、部署能力、宿主机或 WSL 中的系统级副作用,以及已知凭据脱敏;CI 中的第三方 Actions 固定到提交哈希并禁用凭据持久化,来源、贡献者和上游项目也有细致署名。扣分主要因为产品以无人确认的持续自治为核心,并明确可能使用 danger-full-access 或 bypassPermissions;安全红线主要是提示词约束,所给材料没有展示强制权限隔离、完整的数据目的地清单或通用秘密检测。共识文件失败后可恢复,但产品代码和外部副作用不会自动回滚。

2可靠稳定11 / 14 · 3.9/5

README、CI 和专项测试共同展示了熔断、限流退避、超时、进程树清理、配置保留、失败证据以及明确错误信息;依赖和缺失引擎时直接失败的行为也有说明。未给满分之处是依赖安装与版本约束并不完整,且文档存在小幅口径差异,例如动态小队人数同时写为 3–5 和 2–5;本次静态审查也没有执行这些测试。

3适用触发16 / 18 · 4.4/5

材料清楚区分 macOS、Windows/WSL、引擎、语言和前台/守护场景,给出多种环境覆盖方式,并明确实验性质、平台前提、引擎差异和不支持自动回退等边界。触发和路由通过 Next Action、周期阶段及六类流程定义,具有可操作性;但它们主要依赖自然语言提示和模型判断,缺少严格、机器可验证的触发优先级与冲突处理,因此 trigger_precision 未给满分。

4规范维护15 / 18 · 4.2/5

README 提供平台导航、架构、目录、命令速查、安装步骤、FAQ、限制、联系方式和双语文档索引,MIT 正文与元数据一致,因此多数文档规范项证据充分。扣分在于 package.json 名称 auto-company-clone-win 与仓库产品名不完全稳定,只有 1.6.0 版本字段而未提供变更日志或发布策略;维护联系人明确,但发布者未由给定企业注册表验证,且材料没有展示正式维护治理或支持承诺。

5有效结果10 / 13 · 3.8/5

看板、日志、周期摘要、共识记忆、可检查的项目源码和产品示例形成了可直接使用的输出链,持续编排相较单次 CLI 调用具有明确增量价值。扣分因为广泛自治的实际收益仍主要由项目自述和示例支持,而每轮都会消耗模型额度、可能产生部署等外部成本,README 也明确警告稳定性与意外产出风险;没有量化收益、成本上限效果或用户结果比较。

6证据核验6 / 8 · 3.8/5

README 将架构和行为指向具体文件、命令与文档,CI 又列出跨平台、集成、浏览器和产品测试,提供了一定的跨来源对应;还明确区分模型填写的标题摘要与程序采集的运行事实,并披露失败、缺失和人工修正,因此事实与推断分离较好。扣分因为所给证据不含多数核心实现文件、运行记录正文或 CI 结果,实际运行、截图来源和 24/7 等主张无法在本次静态材料中独立确认。

证据充分度: 评估于 2026年9月23日 审查版本 b38ec7bbcb54
源码中未见的安全控制:最小权限约束、执行前用户确认
使用前请注意
  • 默认按高风险本地自动化处理:在审查行为前不要启用 danger-full-access、bypassPermissions 或无人值守守护模式。
  • 先使用前台运行、受限沙箱、低额度账户和无生产凭据的隔离工作区;持续检查 projects、docs、logs 及实际网络目的地。
  • 提示词安全红线不是强制沙箱。部署、营销、仓库写入及其他外部副作用需要额外的操作系统、账户和服务端权限边界。
  • 共识回滚不等于事务回滚;代码修改、发布和远端资源变更可能需要人工恢复。
  • 本评估仅基于所附静态文件,未运行测试、验证 CI 状态或检查未提供的核心实现。
评估证据 [1][2][3][4][5][6][7]
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

Auto Company 是一套自托管的多智能体工作流,通过持续循环在本机组织 14 个专家角色和 30 多项可复用技能。核心脚本 scripts/core/auto-loop.sh 每轮读取 PROMPT.md 与 memories/consensus.md,调用 Claude Code 或 Codex CLI,并为当前任务组成 2 至 5 人的小队。团队可以研究机会、评估产品、编写和测试代码、部署项目并准备营销材料,生成物保存在 projects/、docs/ 和 logs/ 等目录中。跨轮次状态被压缩到单个 memories/consensus.md 文件,用户可通过编辑 Next Action 改变方向。项目还提供本地 Dashboard,用于查看周期报告、结果、状态、用量、预算和日志,但不会跟踪每个智能体的活动。它适合愿意在 macOS 或 Windows/WSL 上自行管理模型权限、额度、运行风险和产出复核的用户。

启动后,auto-loop.sh 读取 PROMPT.md、CLAUDE.md、.claude/skills/team/SKILL.md 和 memories/consensus.md,再通过 Claude Code 或 Codex CLI 发起一次独立执行。系统依据 consensus.md 中的 Next Action,从 14 个专家角色中动态选择 2 至 5 个成员,执行研究、产品判断、编码、测试、部署或营销工作。每轮结束前,它重写 memories/consensus.md 作为下一轮的交接状态,并将引擎输出、周期结果及可用的用量记录写入 logs/,将项目放入 projects/,将文档型产出放入 docs/。循环包含限流等待、连续错误熔断和失败后的共识恢复;产品代码改动及外部副作用不会自动回滚。本地 dashboard/ 汇总当前及历史周期、运行控制、状态、预算、用量和日志;守护进程在 macOS 使用 launchd,在 Windows/WSL 使用 systemd --user。

  1. 独立开发者希望让本机 AI 团队连续完成产品构思、验证、实现和发布,并能定期检查实际产出。
  2. 产品负责人需要用固定的 GO/NO-GO 流程评估新产品方向,并让研究、财务、产品和技术角色共同给出结论。
  3. 工程团队想把功能工作按交互设计、UI、全栈开发、QA 和 DevOps 的顺序交给多角色工作流执行。
  4. 创业者需要在没有复杂外部状态数据库的情况下,通过一个 consensus.md 文件持续调整自动化团队的下一步任务。
  5. 需要长期运行本地自动化的 macOS 或 Windows/WSL 用户,希望通过 Dashboard、日志、预算提醒和熔断机制观察运行情况。

这个 Agent 有哪些优点和局限?

优点
  • 提供从持续循环、动态组队到状态交接的完整本地编排,而不只是一次性的提示词集合。
  • Claude Code 与 Codex CLI 都有明确的启动入口,macOS 和 Windows/WSL 也分别提供 launchd、systemd --user 及 PowerShell 控制脚本。
  • 用单个 memories/consensus.md 保存跨周期状态,便于人工检查、修改 Next Action 和恢复失败前的共识。
  • 内置本地 Dashboard、周期报告、日志、用量与预算视图,并明确展示缺失、失败、陈旧或不完整的证据。
  • 包含限流退避、连续错误熔断、超时控制和共识恢复机制,适合长期运行实验。
局限
  • 项目明确标为实验性,虽然可以运行,但稳定性不受保证,长期自主执行需要持续人工复核。
  • 每一轮都会消耗模型额度并可能产生费用;所选引擎缺失或额度不可用时,系统不会自动切换到备用引擎。
  • 高自治模式可能依赖 Codex danger-full-access 或 Claude bypassPermissions,系统操作会直接发生在主机或 WSL 环境中。
  • 失败恢复不会自动撤销产品代码改动或外部副作用,部署、发布及其他外部操作仍可能需要人工处理。
  • Windows 必须依赖 WSL2,且 Windows 与 WSL 两侧均有运行时要求;原生 Linux 并未在快速启动支持范围中单独承诺。
  • Dashboard 不跟踪单个智能体的活动,引擎输出也不保证包含完整推理轨迹。

如何安装或部署这个 Agent?

准备 macOS,或带 WSL2 Ubuntu 且支持 systemd --user 的 Windows 10/11。安装 Python 3.10+、Git、make、Node.js,以及已完成认证并有可用额度的 Claude Code 或 Codex CLI。然后执行:

git clone https://github.com/MaxMiksa/Auto-Company.git
cd Auto-Company

macOS 或 WSL 的首次前台运行可执行 make start;若使用 Codex,则执行 ENGINE=codex make start。macOS/WSL 守护模式执行 make install,Codex 守护模式执行 ENGINE=codex make install。Windows 从 PowerShell 执行 .\scripts\windows\start-win.ps1;选择 Codex 时执行 .\scripts\windows\start-win.ps1 -Engine codex。Windows 还需要在 WSL 内安装并认证所选 CLI,并在 Windows 侧提供 Python 3.10+ 供 Dashboard 和本地语言命令使用。

如何使用这个 Agent?

建议先以前台模式运行:默认 Claude Code 使用 make start,Codex 使用 ENGINE=codex make start。用 make monitor 查看实时日志,make cycles 查看周期摘要,make dashboard 打开本地 Dashboard,前台任务可用 make stop 停止。守护模式下应使用 make pause 持续暂停,并用 make resume 恢复,因为单独执行 make stop 可能触发自动重启。Windows 分别使用 .\scripts\windows\status-win.ps1、monitor-win.ps1、dashboard-win.ps1 和 stop-win.ps1。若要改变团队方向,编辑 memories/consensus.md 中的 Next Action;下一轮会读取该变更。可通过 ENGINE、MODEL、LOOP_INTERVAL、CYCLE_TIMEOUT_SECONDS、MAX_CONSECUTIVE_ERRORS、CLAUDE_PERMISSION_MODE 和 CODEX_SANDBOX_MODE 等变量调整引擎及运行限制。运行期间应定期审查 docs/、projects/、日志、用量和预算。

这个 Agent 与同类方案有什么区别?

Claude Code 是默认引擎,Codex CLI 是有明确命令支持的替代方案;两者都需要分别安装、认证并拥有可用额度,系统不会在它们之间自动故障转移。Cursor 和 OpenAI-compatible 适配器也被列出,但必须显式配置,其工具能力与团队能力可能不同,因此不能视为与默认引擎完全等价。

常见问题

它会产生哪些费用?
每个周期都会调用所选模型引擎并消耗模型额度。项目不提供免费运行保证,用户需要监控 Dashboard 中可用的用量和预算信息。
必须授予完全主机权限吗?
不一定。Claude 可配置 CLAUDE_PERMISSION_MODE,Codex 可用 CODEX_SANDBOX_MODE=workspace-write 调整沙箱;但项目说明当前边界依赖底层 CLI 配置,高权限模式下操作会直接影响主机或 WSL。
引擎报错或触发限流后会怎样?
循环包含 429 限流等待、连续错误熔断、周期超时和失败后的 consensus.md 恢复。不过产品代码改动与外部副作用不会随之自动回滚。
可以随时干预正在运行的团队吗?
可以。编辑 memories/consensus.md 的 Next Action 会影响下一周期;守护模式还可通过 make pause 和 make resume 暂停或恢复。
它能直接在普通 Windows 环境运行吗?
执行核心依赖 WSL2 Ubuntu 和 systemd --user;PowerShell 脚本只是 Windows 控制层。所选 Claude Code 或 Codex CLI 必须安装并认证在 WSL 内。

对比同类 Agent

用同一套 FARS 评审,横向比较这个 Agent 所属的短名单。

相关 Agents