Centaur 是什么

Centaur 可以理解为 团队级 AI Agent 的控制平面（control plane）。它并不是单个聊天机器人，而是一个用于运行和管理 Agent 的系统基础设施。

核心特性包括：

• 多人协作（Multiplayer）：多个团队成员可以同时与同一个 Agent 互动
• Slack 原生界面：直接在 Slack 线程中调用和协作
• API 接入：可集成到公司内部系统
• 自托管部署：运行在企业自己的服务器或云环境中

这种设计的目标是让 AI Agent 能够在企业内部完成真实任务，而不仅仅是回答问题。

“多人 Agent”如何工作

大多数 AI 助手是围绕单个用户设计的：用户提问，模型回答。

Centaur 则把 Agent 设计为 团队共享的协作实体。

在 Slack 线程或 API 调用中，Agent 可以：

• 理解团队成员的指令
• 调用内部或外部工具
• 执行多步骤工作流
• 在对话中实时汇报进度

由于 Agent 是共享的，团队成员可以在同一个线程中 观察、调整或继续它的工作。这种模式让 Agent 更像是一个“虚拟团队成员”。

系统还允许将企业内部服务暴露为 类型化工具（typed tools），使 Agent 可以安全调用数据库、内部 API 或运营系统。

支持长时间运行的工作流

许多 AI 工具只能处理一次性请求，而 Centaur 专门为 长期任务（long‑running tasks） 设计。

Agent 可以：

• 持续运行数小时甚至数天
• 在系统重启后恢复执行
• 在任务中协调多个步骤或工具

这意味着 AI Agent 可以承担复杂自动化流程，例如数据分析、研究任务或跨系统操作。

Centaur 通过记录每个阶段的执行过程来保证可靠性，从用户请求、运行分配到最终结果都会被追踪，从而在失败时恢复或审计流程。

PostgreSQL 持久状态存储

Centaur 使用 PostgreSQL 存储运行状态，使 Agent 的执行具备持久性。

数据库会记录多个关键事件，例如：

• 用户输入
• Agent 运行分配
• 执行事件和流式输出
• 任务终止状态和最终结果

这种事件记录机制使系统能够在重启后继续任务，同时保留完整的交互历史。

安全架构：凭证不会暴露给 Agent

AI Agent 在企业环境中的最大风险之一是 凭证泄露。

Centaur 的安全设计采取了一个关键策略：

Agent 永远不会直接看到真实的 API Key 或 Token。

具体做法是：

• 凭证在网络层注入
• Agent 请求通过代理或防火墙处理
• 工具调用时临时附加凭证

因此 Agent 可以使用真实权限执行任务，但 无法读取或泄露原始密钥。

该架构还试图防御多种 Agent 安全风险，例如：

• Prompt 注入攻击
• 恶意网页或文件内容
• 非授权工具调用

系统通过隔离运行环境和严格控制工具权限来降低这些风险。

Paradigm 内部的使用场景

在开源之前，Paradigm 已将 Centaur 部署在多个部门。公司表示它显著改变了团队的工作方式。

已公开的应用领域包括：

• 投资研究与分析
• 工程开发流程
• 产品或视觉设计
• 招聘与人才筛选
• 活动组织
• 客户支持

这些场景的共同点是：需要跨工具协作、持续执行任务并与团队沟通进度。

可扩展的工具与工作流系统

企业可以通过扩展 Centaur 来接入自己的系统。

例如：

• 将内部服务封装为 Python 工具
• 定义自动化工作流
• 使用 overlay 扩展组织专属功能

这种机制允许公司逐步构建一个 共享的 Agent 工具生态，而不是为每个自动化任务重新开发一套系统。

在开源 AI Agent 生态中的位置

当前 AI Agent 框架正在快速增长，但许多项目更偏向实验性自主 Agent。

Centaur 的定位略有不同：它更关注 企业级可靠性与基础设施能力，例如：

• 持久内存
• 安全凭证管理
• 工作流编排
• 团队协作 Agent

通过将这些能力集中到一个运行时层，Centaur 试图成为企业 AI Agent 的基础平台。

这种角色有点类似于 Kubernetes 在容器生态中的作用：为复杂系统提供统一的运行与管理基础设施。

如果 AI Agent 在企业内部持续普及，那么像 Centaur 这样的 Agent Runtime 层 可能会成为下一代 AI 软件架构的重要组成部分。

Centaur 是什么

Centaur 可以理解为 团队级 AI Agent 的控制平面（control plane）。它并不是单个聊天机器人，而是一个用于运行和管理 Agent 的系统基础设施。

核心特性包括：

• 多人协作（Multiplayer）：多个团队成员可以同时与同一个 Agent 互动
• Slack 原生界面：直接在 Slack 线程中调用和协作
• API 接入：可集成到公司内部系统
• 自托管部署：运行在企业自己的服务器或云环境中

这种设计的目标是让 AI Agent 能够在企业内部完成真实任务，而不仅仅是回答问题。

“多人 Agent”如何工作

大多数 AI 助手是围绕单个用户设计的：用户提问，模型回答。

Centaur 则把 Agent 设计为 团队共享的协作实体。

在 Slack 线程或 API 调用中，Agent 可以：

• 理解团队成员的指令
• 调用内部或外部工具
• 执行多步骤工作流
• 在对话中实时汇报进度

由于 Agent 是共享的，团队成员可以在同一个线程中 观察、调整或继续它的工作。这种模式让 Agent 更像是一个“虚拟团队成员”。

系统还允许将企业内部服务暴露为 类型化工具（typed tools），使 Agent 可以安全调用数据库、内部 API 或运营系统。

支持长时间运行的工作流

许多 AI 工具只能处理一次性请求，而 Centaur 专门为 长期任务（long‑running tasks） 设计。

Agent 可以：

• 持续运行数小时甚至数天
• 在系统重启后恢复执行
• 在任务中协调多个步骤或工具

这意味着 AI Agent 可以承担复杂自动化流程，例如数据分析、研究任务或跨系统操作。

Centaur 通过记录每个阶段的执行过程来保证可靠性，从用户请求、运行分配到最终结果都会被追踪，从而在失败时恢复或审计流程。

PostgreSQL 持久状态存储

Centaur 使用 PostgreSQL 存储运行状态，使 Agent 的执行具备持久性。

数据库会记录多个关键事件，例如：

• 用户输入
• Agent 运行分配
• 执行事件和流式输出
• 任务终止状态和最终结果

这种事件记录机制使系统能够在重启后继续任务，同时保留完整的交互历史。

安全架构：凭证不会暴露给 Agent

AI Agent 在企业环境中的最大风险之一是 凭证泄露。

Centaur 的安全设计采取了一个关键策略：

Agent 永远不会直接看到真实的 API Key 或 Token。

具体做法是：

• 凭证在网络层注入
• Agent 请求通过代理或防火墙处理
• 工具调用时临时附加凭证

因此 Agent 可以使用真实权限执行任务，但 无法读取或泄露原始密钥。

该架构还试图防御多种 Agent 安全风险，例如：

• Prompt 注入攻击
• 恶意网页或文件内容
• 非授权工具调用

系统通过隔离运行环境和严格控制工具权限来降低这些风险。

Paradigm 内部的使用场景

在开源之前，Paradigm 已将 Centaur 部署在多个部门。公司表示它显著改变了团队的工作方式。

已公开的应用领域包括：

• 投资研究与分析
• 工程开发流程
• 产品或视觉设计
• 招聘与人才筛选
• 活动组织
• 客户支持

这些场景的共同点是：需要跨工具协作、持续执行任务并与团队沟通进度。

可扩展的工具与工作流系统

企业可以通过扩展 Centaur 来接入自己的系统。

例如：

• 将内部服务封装为 Python 工具
• 定义自动化工作流
• 使用 overlay 扩展组织专属功能

这种机制允许公司逐步构建一个 共享的 Agent 工具生态，而不是为每个自动化任务重新开发一套系统。

在开源 AI Agent 生态中的位置

当前 AI Agent 框架正在快速增长，但许多项目更偏向实验性自主 Agent。

Centaur 的定位略有不同：它更关注 企业级可靠性与基础设施能力，例如：

• 持久内存
• 安全凭证管理
• 工作流编排
• 团队协作 Agent

通过将这些能力集中到一个运行时层，Centaur 试图成为企业 AI Agent 的基础平台。

这种角色有点类似于 Kubernetes 在容器生态中的作用：为复杂系统提供统一的运行与管理基础设施。

如果 AI Agent 在企业内部持续普及，那么像 Centaur 这样的 Agent Runtime 层 可能会成为下一代 AI 软件架构的重要组成部分。