Puppyone 上下文驱动器
为 AI 代理提供基于 Git 的云文件系统，每个代理都有文件级权限和多种访问方式。
证据显示：README 声称有文件级权限（FLS）和审计日志，但未提供实现细节；SECURITY.md 提供漏洞报告和密钥处理指南；Docker 部署默认共享 Docker socket，存在安全风险；未发现用户确认机制；数据流不透明；敏感数据处理仅提及环境变量；依赖安全仅提及使用锁文件和 Dependabot；外部影响包括 Docker socket 挂载和网络服务；回滚功能在 README 中提及；来源归属未明确。扣分原因：权限和审计仅为声称，无代码证据；用户确认缺失；数据流不透明；敏感数据处理不充分；依赖安全仅提及；外部影响有风险；回滚未验证；来源归属不明确。
证据显示：README 描述一致，但存在不一致之处（如 SECURITY.md 提到 PuppyAgent 商标，而 README 提到 Puppyone）；依赖可用性未验证；失败消息未提及。扣分原因：自洽性因商标不一致而扣分；依赖可用性未验证；失败消息缺失。
证据显示：README 明确目标用户（AI agents）和场景（CLI、MCP、Git、SSH）；能力边界部分描述（如支持多种连接器）；触发精度未明确；环境适配良好（支持 Docker、云、自托管）。扣分原因：能力边界不完整；触发精度未明确。
证据显示：信息架构清晰（README 有目录）；安装说明详细（Docker、CLI）；命名稳定性未明确；示例和 FAQ 有限；已知限制未明确；许可证为 Apache-2.0；版本变更日志缺失；维护责任未明确。扣分原因：命名稳定性未明确；示例和 FAQ 有限；已知限制未明确；版本变更日志缺失；维护责任未明确。
证据显示：输出可用性未明确；边际价值高（提供多种访问方式）；成本效益未明确。扣分原因：输出可用性未明确；成本效益未明确。
证据显示：README 中的声明部分可追溯（如功能列表）；跨来源验证有限（仅 README 和 SECURITY.md）；事实与推断未明确分离。扣分原因：跨来源验证有限；事实与推断未分离。
- Docker 部署默认共享 Docker socket，存在安全风险，远程或多租户部署应使用 E2B 沙箱。
- README 声称的文件级权限和审计日志缺乏代码证据，需进一步验证。
- SECURITY.md 中提及 PuppyAgent 商标，与 README 中的 Puppyone 不一致，可能影响品牌一致性。
这个 Agent 能做什么，适合哪些场景？
Puppyone 是一个用于 AI 代理的上下文托管平台，将来自各种来源的数据组织到名为 Context Drive 的云文件系统中。每个代理都通过 Git 支持的文件级权限（称为 FLS）获得对其文件的安全隔离访问。该系统支持通过 CLI、MCP、REST API、沙箱和文件夹同步进行多种访问方式，让代理以首选方式安全地获取上下文。它通过 Docker Compose 提供自托管部署，其中包括 PostgreSQL、Supabase 认证、Redis、MinIO 和 FastAPI 后端。该产品旨在通过集中和治理代理的上下文，并附带注释、协作工具和 API，以简化 AI 代理的采用。
Puppyone 运行一个后端 API（FastAPI）和一个前端（Next.js 15），并编排一个 Docker Compose 堆栈（PostgreSQL、Supabase、Redis、MinIO）。它从各种 SaaS 源（GitHub、Gmail、Google Drive 等）摄取数据，将其转换为 Markdown/JSON 并存储在 Context Drive 中。管理员创建项目并定义访问点 CLIs：puppyone access add url 和 puppyone access add mcp。每个代理通过 MCP 端点、REST API 或 CLI 连接，该 CLI 使用 puppyone auth login 和 puppyone project use 命令。系统实施文件级安全，通过 Docker 或 E2B 沙箱在挂载授权文件的情况下执行代码。此外，它还提供审计日志、版本历史、回滚和结账/提交工作流。
- 使用 Cursor 或 Claude Desktop 的编码人员需要为代码生成提供管理良好的项目上下文，而无需处理混乱——Puppyone 通过 MCP 提供该上下文。
- 在多个项目中工作的 AI 代理团队希望防止交叉访问——文件级权限强制执行安全边界。
- 在自托管环境中使用受监管数据的组织需要审计跟踪和版本控制，以便代理对文件的读写操作可见。
- 想要将 GitHub、Gmail 和 Google Drive 内容无缝整合到代理工作流中的开发人员，使用内置连接器。
- 构建多代理系统的人需要为不同的代理提供不同的上下文集，交付一个共享的 Context Drive 和多个作用域访问点。
- 使用 E2B 沙箱进行安全代码执行的应用想要在隔离环境中运行代理，仅挂载授权文件。
这个 Agent 有哪些优点和局限？
- 基于 Git 的文件级权限（FLS）为每个代理强制实施安全，确保未经授权的文件不可见。
- 多种访问方式（CLI、MCP、REST API、沙箱、文件夹同步）提供集成灵活性。
- 原生支持常用的数据源连接器（GitHub、Gmail、Google Drive 等）。
- 完整的自托管通过 Docker Compose 实现，包括数据库、存储和认证。
- 完整功能需要多种服务（PostgreSQL、Redis、MinIO），由于 Docker Compose 的尺寸，对轻量级部署可能不利。
- 依赖特定供应商：使用 Supabase 进行认证，使用 E2B 作为可选的沙箱提供者，可能存在锁定风险。
- 需要 Node.js（CLI）和 Python（后端），需要多种运行时环境。
- 文档表明某些功能（如 OAuth 连接器）需要额外配置，自托管设置可能比较复杂。
如何安装或部署这个 Agent？
对于云：在 https://www.puppyone.ai 注册账户。对于自托管：克隆仓库并运行 cd puppyone/docker && cp .env.example .env && docker compose up -d。这将在 http://localhost:3000 启动整个栈（前端）。首次启动需要 1-2 分钟。可选：在 docker/.env 中添加 ANTHROPIC_API_KEY 以启用代理聊天。
如何使用这个 Agent？
安装 CLI：npm install -g puppyone。登录：puppyone auth login（选择 Cloud/Local/Custom URL）。创建项目：puppyone project create "My Project" 和 puppyone project use "My Project"。添加网页：puppyone access add url https://example.com --scope /refs。创建 MCP 端点：puppyone access add mcp "My Context"，然后将输出的 URL/API 密钥配置到 MCP 客户端中。对于自托管，通过 puppyone auth login -u http://localhost:9090 登录。