核心功能
Paperclip 定位为 AI Agent 团队的控制平面（Control Plane），而非执行引擎本身。它提供本地优先的架构设计，让用户能够在自有基础设施上建立 AI 公司的组织结构：定义公司目标、汇报线、工作空间、审批流与预算管控，并通过适配器层连接 OpenClaw、Codex、Claude 等实际执行运行时。
显著优点
1. 本地优先架构：所有实例状态存储于 ~/.paperclip/instances/，无需强制云端账户，满足数据主权敏感场景
2. 企业级治理抽象：原生支持 heartbeat 协调、审批门控（approval gates）、支出上限（spend caps）——这些是多数 Agent 框架缺失的组织运营层
3. 灵活的适配器边界设计：codex_local/claude_local 用于同机执行，openclaw_gateway 用于跨网络雇佣外部 Agent，架构决策清晰
4. 可审计的操作界面：CLI 与 API 优先，鼓励小型可重复命令而非不可追踪的聊天交互
潜在局限与风险
- 学习曲线陡峭：需先理解"公司建模"概念（目标、汇报关系、工作空间）才能发挥价值，否则易沦为并行标签管理器
- 多运行时依赖：Codex/Claude 适配器要求本地 CLI 已安装并认证，否则 heartbeat 失败
- 网络配置陷阱：OpenClaw Docker 内使用
localhost会指向容器自身而非 Paperclip 主机，需显式配置网关地址 - 并发语义依赖：必须遵循 Paperclip 的 issue checkout 机制，否则多 Agent 会踩踏同一任务
适合人群
- 需要为 AI Agent 团队建立成本管控与审批治理的技术负责人
- 偏好本地数据驻留的企业用户与隐私敏感场景
- 已运行 OpenClaw、Codex 或 Claude，希望统一协调层而非分散管理的开发者
常规风险提示
- 认证凭据（Paperclip API key、OpenAI/Anthropic keys、OpenClaw token）需妥善管理于环境变量，避免硬编码
- 外部流量仅发送至用户配置的 Paperclip API 端点与 OpenClaw 网关，无强制云端回传，但需自行评估目标部署的可信度