一、调研背景
智能体编排(Agent Orchestration)正在成为新一代AI产品形态的核心范式。本报告深度调研三种代表性路径:
- Multica — 看板驱动 + CLI委托执行,"智能体即队友"范式
- Sutra OS — 可视化DAG工作流 + LangGraph推理引擎,"智能体即组织成员"范式
并与我们自身的"Process First + Skill工程化"路径做对比分析,明确差异、可借鉴点与需警惕的陷阱,为产品方向提供决策依据。
二、Multica完整功能分析
产品基本信息
GitHub:https://github.com/multica-ai/multica 8.6K Stars Apache 2.0
定位:开源的"托管智能体"平台,Anthropic Claude Managed Agents 的开源替代品
Tagline:"Your next 10 hires won't be human"
技术栈:Go(Chi路由器 + WebSocket)+ Next.js 16(App Router)+ PostgreSQL 17 + pgvector
Issue/Task管理功能点
| 功能 | 详细说明 |
|---|---|
| CRUD | 完整的创建、读取、更新、删除操作 |
| 状态机 | ENQUEUED → CLAIMED → IN_PROGRESS → DONE / FAILED,严格单向流转 |
| 优先级 | 多级优先级设置,影响Agent拾取顺序 |
| 标签 | 自定义标签体系,支持按标签筛选与分配 |
| 分配 | 手动指定Agent或自动拾取(Agent自动认领) |
| 评论线程 | 人类与Agent都可在Issue下评论,形成讨论线程 |
| 阻塞报告 | Agent主动报告阻塞(缺少信息、依赖未完成等),阻塞信息在看板突出显示 |
| 依赖追踪 | Issue之间的前后依赖关系,前置未完成则后续不执行 |
| Inbox视图 | 未分配任务统一入口,类似邮箱收件箱 |
| Board视图 | 看板拖拽视图,类似GitHub Projects |
Agent管理功能点
| 功能 | 详细说明 |
|---|---|
| Profile | 每个Agent有独立身份配置(名称、角色描述、专属技能) |
| 11种Provider | Claude Code, Codex, Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, Kiro CLI |
| 自动拾取 | Agent空闲时自动从队列认领匹配任务 |
| 进度流式上报 | WebSocket实时推送Agent执行进度到前端 |
| 主动报阻塞 | Agent遇到问题时主动标记Issue为blocked并说明原因 |
| 创建子Issue | Agent在执行过程中可动态创建子任务 |
| Skills绑定 | 每个Agent可绑定多个Skill,影响任务拾取匹配 |
| Custom Args | 支持自定义参数注入,灵活配置Agent行为 |
| 超时2h | 单任务执行超时上限2小时 |
| 并发20 | 单个Runtime最大并发任务数20 |
| Multi-Profile | 同一Provider可配置多个Profile(不同模型/参数组合) |
Skill系统功能点
| 功能 | 详细说明 |
|---|---|
| Markdown格式 | Skill以纯Markdown编写,包含指令、工作流、脚本、文档、元数据 |
| 结构化内容 | 指令(Instructions) + 工作流(Workflow) + 脚本(Scripts) + 文档(Docs) + 元数据(Meta) |
| 从任务自动提取 | Agent完成任务后,系统可自动从执行过程中提取并生成Skill |
| Lockfile版本 | Skill有版本锁文件,确保团队使用一致版本 |
| Team-wide分发 | Skill在工作区内共享,全团队可复用 |
| Per-Task注入 | 任务粒度注入Skill,不同任务可使用不同Skill组合 |
| pgvector推荐 | 基于向量相似度自动推荐匹配任务的Skill |
| 复利增长 | 每次解决的问题都变成可复用Skill,团队知识随时间复利增长 |
Runtime管理功能点
| 功能 | 详细说明 |
|---|---|
| 本地Daemon | 本地守护进程,3秒轮询获取新任务 |
| 云Runtime | 支持云端运行时,无需本地部署 |
| CLI自动检测 | 自动检测本机已安装的CLI工具(Claude Code等) |
| 心跳15s | 15秒心跳间隔,断线自动标记Agent不可用 |
| Per-Task目录隔离 | 每个任务独立工作目录,避免文件冲突 |
| GC策略 | 已完成任务24h清理、孤立任务72h清理、工件12h清理 |
| 保留.git | GC时保留.git目录,防止版本历史丢失 |
| 自动更新 | Daemon自动检测并更新到最新版本 |
| 日志 | 完整的运行时日志记录与查看 |
Autopilot自动化
| 功能 | 详细说明 |
|---|---|
| Cron定时 | 支持Cron表达式定时触发任务 |
| 事件触发 | Issue创建 / 状态变更 / 评论 / Webhook四种事件源 |
| 自动创建Issue | 触发后自动创建新Issue并分配Agent |
| 直接调用Agent | 触发后直接让指定Agent执行操作 |
| 参数化 | 触发规则支持参数化配置,灵活适应不同场景 |
| 条件判断 | 触发时可设置前置条件,满足才执行 |
编排机制核心决策
核心设计:不自建Agent Loop,委托给第三方CLI
Multica最核心的架构决策是不自建Agent执行循环,而是将任务委托给第三方CLI工具(Claude Code、Codex等)执行。
| 维度 | 说明 |
|---|---|
| 代价 | 不能Hook中间步骤;Agent是黑盒;无DAG工作流编排 |
| 收益 | 技术栈极简;多厂商即插即用;Agent能力随Provider自动升级 |
| 冲突避免 | Per-Task目录隔离 + Git分支隔离 + 1:1分配原子Claim |
| 当前不支持 | DAG编排、条件网关、自动重试、Fallback Agent |
数据模型
Agent(id, workspace_id, name, provider, runtime_id, custom_args, skills[])
Runtime(id, workspace_id, daemon_id, available_providers[], status, max_concurrent_tasks)
Skill(id, workspace_id, name, markdown_content, version, embedding, used_count)
TaskMessage(id, issue_id, sender_id, sender_type, content, message_type)
Autopilot(id, trigger_type, trigger_cron, trigger_event, action_type, target_agent_id)
三、Sutra OS完整功能分析
产品基本信息
官网:https://sutra.gauravdatar.com/
GitHub:https://github.com/datar-gaurav/sutra-os
定位:多智能体推理编排平台(完整堆栈的组织模拟)
作者:Gaurav Datar(个人开源项目)
技术栈:FastAPI + LangGraph + Next.js 14 + PostgreSQL 16 + pgvector + Redis 7 + Celery
工作流编辑器(9+节点类型)
Sutra的核心是React Flow驱动的可视化DAG工作流编辑器,支持以下节点类型:
| 节点类型 | 功能 | 关键属性 |
|---|---|---|
| input | 工作流入口,接收外部输入 | 输入变量定义、默认值 |
| agent | 调用指定Agent执行推理 | agent_id、system_prompt覆盖、工具选择 |
| conditional | 条件分支,由Agent评估自然语言条件 | 条件表达式、true/false出口 |
| parallel | 并行扇出,多个分支同时执行 | 扇出数量、分支配置 |
| approval_gate | 人类在环审批门,暂停等待人工决策 | 审批分类、风险等级、超时设置 |
| loop | 循环执行,直到满足退出条件 | 最大轮次、退出条件 |
| discussion | 多Agent讨论节点 | 讨论格式、参与者、轮次 |
| sub_workflow | 嵌套子工作流调用 | 引用的工作流ID、参数映射 |
| webhook | 外部Webhook触发/回调 | URL、Method、Headers |
连接规则
- DAG强制:不允许循环依赖,工作流必须是DAG
- 拓扑排序:节点按拓扑序执行
- 条件分支sourceHandle:条件节点通过sourceHandle区分true/false出口
- 并行扇出:parallel节点同时启动所有分支
- 前驱输出拼接:多前驱节点的输出用分隔符合并后传入当前节点
条件分支与并行执行
条件分支实现
Agent评估自然语言条件
- Prompt格式:
"Evaluate whether [条件]. Answer ONLY YES/NO" - 回复以"YES"开头则判定为true,否则为false
- 失败默认true — 条件评估失败时默认走true分支(乐观假设)
- 同步阻塞等待结果
并行执行实现
| 特性 | 实现 |
|---|---|
| 并发机制 | asyncio.gather()真正并发执行 |
| 超时控制 | 每分支独立超时设置 |
| 结果合并 | 各分支结果用"---"分隔后join |
| 跳过标记 | 分支标记skipped防止重复执行 |
智能体系统完整属性
| 属性 | 说明 |
|---|---|
name | 智能体唯一名称 |
system_prompt | 系统提示词,定义角色行为 |
role | 组织角色(CEO、工程师、分析师等) |
llm_provider | 6种Provider(OpenAI、Anthropic、Google、Groq、Ollama、LM Studio) |
llm_model | 具体模型选择 |
temperature | 生成温度 |
max_tokens | 单次最大生成Token数 |
enabled_tools | 可用工具白名单 |
max_tool_calls_per_run | 单次运行最大工具调用次数 |
max_tokens_per_day | 每日Token预算上限 |
purpose_id | 关联的组织目的/目标 |
status | 智能体运行状态 |
能力边界控制
- 工具白名单:只能使用enabled_tools中声明的工具
- Token预算:max_tokens_per_day限制每日消耗
- 递归限制:默认31步,防止无限循环
- 提示注入:系统级约束通过system_prompt注入
多Agent讨论(5种格式)
| 格式 | 用途 | 特点 |
|---|---|---|
| brainstorm | 头脑风暴,发散创意 | 鼓励自由联想,不批判 |
| debate | 辩论,正反方对立 | 刻意制造对立观点 |
| review | 审查,挑问题找缺陷 | 以批判视角审视输出 |
| standup | 站会,同步进度 | 每人简短汇报状态 |
| retrospective | 回顾,总结经验 | 反思什么好什么可改进 |
- 轮次:由
max_rounds控制,每轮所有参与者依次发言 - 结论生成:Moderator角色在讨论结束后生成SUMMARY + ACTION ITEMS
人类在环审批门
| 维度 | 详细说明 |
|---|---|
| 触发方式 | 显式approval_gate节点 或 Agent调用request_approval |
| 分类 | financial / external / destructive / strategic / general 五种 |
| 等级 | low / medium / high / critical 四级 |
| 流程 | 暂停工作流 → 创建ApprovalRequest → 前端展示 → 人工Approve/Reject → 恢复或失败 |
| 过期 | expires_at自动失效,防止无限等待 |
知识库RAG
| 维度 | 实现 |
|---|---|
| 支持格式 | PDF / Text / URL / File |
| 分块策略 | RecursiveCharacterTextSplitter,chunk_size=1000,overlap=150 |
| 检索算法 | 0.7 × 余弦相似度 + 0.3 × 关键字匹配(混合检索) |
| 注入方式 | 工具主动搜索 / Orchestrator被动注入 / 讨论预取 |
三层内存系统
| 层级 | 特点 | 内容 |
|---|---|---|
| Core | 永不衰减,固定上下文 | 身份、规则、核心约束 |
| Recall | 半衰期7天,向量搜索 | 对话历史、临时决定、近期交互 |
| Archival | 长期存储,低频访问 | 历史归档、已完成任务 |
写入与搜索
- 写入:Agent主动
save_memory/ 系统auto-extract/promote晋升(Recall→Core) - 搜索:向量化 +
decay_score加权排序,时间越近权重越高
工具集成(30+完整清单)
| 类别 | 工具 | 数量 |
|---|---|---|
| Core Agent | ask_agent, control_agent, discuss_with_agent | 3 |
| OS | read_file, write_file, list_directory, search_files, run_shell_command, get_system_info 等 | 10 |
| Developer | GitHub issue/PR/commit/search, run_gemini_cli | 7 |
| Data | analyze_data, scrape_webpage, google_sheet | 5 |
| Knowledge | save_memory, search_memory, update_memory, forget_memory, promote_memory | 5 |
| Communication | email, webhook, telegram, slack | 7 |
| Integrations | Notion, Linear, Jira, Slack, GitLab 等 | 15+ |
| Business Logic | task CRUD, decompose_task, discussion, approval, KB | 8 |
| Autonomy | goals, schedule_self, triggers | 6 |
| Browser | open, click, type, screenshot, extract, scroll, navigate 等 | 12 |
Agent委派机制与错误处理
Agent委派
调用链路
Agent A 调用 ask_agent(agent_id="B", prompt="...")
→ Orchestrator路由到Agent B
→ 构建消息上下文
→ LangGraph执行
→ 返回结果给Agent A
- 阻塞式:A等待B完成才继续
- 上下文不共享:B看不到A的对话历史
- 错误处理:B执行失败则返回错误字符串
- Token计费:A和B各自独立计费
错误处理
| 机制 | 详细说明 |
|---|---|
| 超时 | 节点级300秒默认超时 |
| 重试 | 5轮回退策略(速率限制→排除当前模型→尝试下一个Provider) |
| 熔断器 | 连续失败→打开熔断→冷却30s→半开→恢复/继续熔断 |
| Token卫士 | 自动修剪消息历史、紧急修剪策略 |
| 递归限制 | 默认31步,防止Agent无限循环 |
四、两产品横向对比
| 维度 | Multica | Sutra OS |
|---|---|---|
| 编排方式 | 看板+CLI委托 | 可视化DAG+LangGraph |
| 编排对象 | 第三方CLI Agent | 自有Agent(LangGraph驱动) |
| 技术栈 | Go + Next.js + PG17 | FastAPI + LangGraph + Next.js14 |
| Agent自主性 | 高(委托后黑盒执行) | 中(DAG约束内自主推理) |
| 工作流复杂度 | 低(无DAG、无网关) | 高(9+节点、条件/并行/循环/审批) |
| 条件分支 | 不支持 | Agent评估自然语言条件 |
| 并行执行 | 多Agent并发(1:1 Claim) | asyncio.gather()扇出 |
| 人类在环 | 看板交互+评论 | 审批门+风险分级 |
| 知识管理 | Skill复利+pgvector推荐 | RAG知识库+三层内存 |
| Skill系统 | Markdown+版本锁+团队分发 | 工具白名单+能力边界 |
| 工具集成 | 11种CLI Provider | 30+内置工具 |
| 多Agent协作 | 看板1:1分配 | ask_agent委派+5种讨论 |
| 失败处理 | 状态标记FAILED | 重试+熔断+Token卫士 |
| 自进化 | Skill复利增长 | 三层内存晋升 |
| 部署方式 | Docker Compose/云 | Docker Compose |
| 开源程度 | 完全开源 Apache 2.0 | 完全开源 |
| 适用场景 | 编码任务、开发团队 | 通用组织模拟、复杂推理 |
| 局限性 | 无DAG、Agent黑盒、无重试 | 条件评估乐观假设、复杂度高 |
五、我们的产品现状
核心理念:Process First + Harness Engineering
核心原则:AI能力挂载在业务流程节点上(不是面向个人)
流程定义:流程 = 企业交付价值的端到端链路
设计哲学:流程是骨架,AI是肌肉。骨架决定方向,肌肉提供力量
流程编排实现
- 端到端流程,每个节点是一个智能体
- 智能体之间用硬代码/工程方式串联(不是AI自主决策)
- 网关条件是工程师编码的判断规则
- Agent是执行者,不决定下一步
Skill工程体系
| 维度 | 实现 |
|---|---|
| Skill实体定义 | TypeScript定义:namespace, domain, executionType, agentPrompt, status, version, scope |
| 生命周期 | draft → reviewing → published → archived |
| 执行类型 | api / webhook / rpa / agent / manual |
| 质量保障 | 准确率验证、置信度分级、人工确认流 |
实际场景
- 财务预凭证生成:AI + 规则引擎,自动生成会计凭证
- AI审批助手:审批建议 + 风险提示 + 人工确认
- 采购流程自动化:需求→报价→审批→下单→验收端到端
与两个竞品的本质差异
核心差异
- 我们编排的是"流程节点上的确定性Skill" — 他们编排的是"自主决策的Agent"
- 我们追求95%+准确率 — 他们接受不确定输出,通过迭代逼近
- 我们用工程确定性保证业务安全 — 他们用AI灵活性追求探索效率
六、差异分析与产品设计启发
6.1 三条路径对比
| 维度 | 我们(Process First) | Multica(看板委托) | Sutra(DAG推理) |
|---|---|---|---|
| 确定性 | 极高 — 工程规则驱动 | 低 — Agent黑盒执行 | 中 — DAG约束但条件AI评估 |
| 自主性 | 极低 — Agent不决策 | 高 — Agent自主执行 | 中 — DAG内自主推理 |
| 适用场景 | 财务/审批/采购 | 编码/开发 | 组织模拟/通用推理 |
| 错误代价 | 极高 — 财务错误不可逆 | 低 — 代码可回滚 | 中 — 有审批门兜底 |
| 人机关系 | 人是审核者,AI是工具 | 人与Agent是队友 | 人是管理者,Agent是下属 |
6.2 可借鉴的点
绿色:值得引入的设计
- Multica的Skill复利机制:pgvector自动推荐,我们可以加强Skill的向量检索和智能推荐
- Sutra的审批门+风险分级:financial/external/destructive/strategic/general分类 + low/medium/high/critical等级,增强我们现有的人工确认流
- Sutra的多Agent讨论:审批场景下多专家Agent给建议(brainstorm/debate/review),提升审批质量
- Multica的Autopilot:在我们的流程触发中引入Cron定时 + 事件驱动(Issue创建/状态变更/Webhook)
6.3 需要警惕的
黄色:不可照搬的设计
- 不能照搬Agent自主决策到高确定性业务 — 财务错不起,一行凭证错就是审计问题
- Agent as Teammate在B端落地有合规和审计问题 — 谁对Agent的决策负责?审计追踪怎么走?
- Sutra的"乐观假设"(条件评估失败默认true) — 在严肃场景极其危险,应该是失败默认false或暂停
- Multica当前无DAG编排能力 — 说明DAG编排这个问题本身很难,不要低估复杂度
- 纯AI驱动条件判断的准确率 — 在业务场景中不可控,应该用规则引擎+AI辅助
6.4 产品方向思考
演进路线
- 短期:保持Process First,但在流程节点内部引入多Agent协商(比如审批场景下多个专家Agent给出建议)
- 中期:从固定流程 → 流程模板 + Agent灵活执行,在确定框架下给自由度
- 长期:高频稳定场景保持规则驱动,新兴探索场景引入Agent自主编排
具体可落地的改进
- Skill推荐系统:引入向量相似度匹配,类似Multica的pgvector推荐
- 流程审批节点引入多Agent讨论:在关键审批环节让多个专家Agent讨论后给出综合建议
- 流程触发器增加Cron+事件驱动:从纯手动触发到定时/事件自动触发
- 引入风险分级审批:low/medium/high/critical,不同等级不同审批流程
七、产品链接汇总
| 产品 | 官网 | GitHub | 文档 |
|---|---|---|---|
| Multica | multica.ai | GitHub | Docs |
| Sutra | sutra.gauravdatar.com | GitHub | GitHub README |