NocoBase AI 员工上线：多会话并行处理怎么玩？

预计阅读时间：9 分钟

开源无代码/低代码平台 NocoBase 近期发布了一轮产品更新，最值得关注的亮点是 AI 员工支持多个会话并行处理。这意味着在同一个工作流里，你可以让多个 AI 员工同时处理不同会话，而不是排队等待。对于需要批量处理客户咨询、并行审核内容、同时执行多步推理的场景，这个能力直接把吞吐量拉上去了。

下面拆开看看这个能力怎么用、怎么配，以及部署时需要注意什么。

多会话并行：从排队到并发

传统做法里，AI 员工（本质上是挂在大模型 API 上的自动化工作节点）处理任务时是串行的——一个会话结束，下一个才开始。当任务量上来，延迟会明显堆积。

NocoBase 这次更新让 AI 员工可以同时持有多个活跃会话，各自独立推进。核心变化有三点：

会话隔离：每个并行会话有独立的上下文窗口，互不干扰。
调度可控：可以在工作流配置里指定并行度上限，避免 API 限流炸掉。
结果汇聚：并行会话的输出可以在后续节点里合并、筛选或排序。

对于 NocoBase 的三个发布分支，这个功能已经进入 next 分支（包含即将发布的新功能、经过初步测试），稳定版用户需要等它合入 main。当前 main 分支仍是推荐安装的最稳定版本。

在 NocoBase 里配置 AI 员工工作流

NocoBase 的无代码编排界面可以直接拖拽配置 AI 员工节点，但如果你更习惯用配置文件或想批量复用，也可以通过插件配置 YAML 来定义。以下是一个可改造的示例。

示例：配置一个并行处理客户咨询的 AI 员工工作流

假设你有一个客服场景：用户提交咨询后，AI 员工需要同时从"产品知识库"和"订单系统"两个方向检索并生成回复。

# NocoBase AI 员工工作流配置示例（伪配置，基于 NocoBase 插件结构推断）
# 实际字段名请参照 next 分支的最新文档

name: customer_support_parallel
description: AI 员工并行处理客户咨询

triggers:
  - type: form_submit
    collection: customer_inquiries
    fields: [question, customer_id]

nodes:
  # 第一个并行分支：产品知识库检索
  - id: product_search
    type: ai_employee
    parallel_group: support_group
    model: gpt-4o
    prompt_template: |
      你是产品顾问。根据以下用户问题，从产品知识库中检索相关信息并给出建议。
      用户问题：{{question}}
      客户ID：{{customer_id}}
    tools:
      - knowledge_base_search:
          collection: product_docs
          top_k: 5

  # 第二个并行分支：订单状态查询
  - id: order_lookup
    type: ai_employee
    parallel_group: support_group
    model: gpt-4o
    prompt_template: |
      你是订单助手。查询该客户的订单状态，判断是否有待处理问题。
      客户ID：{{customer_id}}
    tools:
      - database_query:
          collection: orders
          filter: { customer_id: "{{customer_id}}" }

  # 汇聚节点：合并两个分支的结果
  - id: merge_response
    type: merge
    depends_on: [product_search, order_lookup]
    merge_strategy: concatenate
    output_format: |
      产品建议：{{product_search.result}}
      订单状态：{{order_lookup.result}}

  # 最终节点：生成统一回复
  - id: final_reply
    type: ai_employee
    model: gpt-4o-mini
    prompt_template: |
      将以下两部分信息整合为一条简洁的客户回复：
      {{merge_response.output}}

parallel_config:
  max_concurrent_sessions: 5   # 并行度上限，防止 API 限流
  timeout_per_session: 30s     # 单会话超时
  retry_on_failure: 2          # 失败重试次数

使用前需要调整的地方：

model 字段改成你实际接入的大模型标识（NocoBase 支持通过插件对接 OpenAI、DeepSeek 等）。
tools 里的 knowledge_base_search 和 database_query 需要在 NocoBase 中先建好对应的集合和索引。
max_concurrent_sessions 根据你的 API 配额设定——OpenAI 的 TPM/RPM 限制是硬约束，设太高会触发 429。

用命令行快速拉起 NocoBase next 分支

如果你想亲自跑一下这个功能，最快的方式是用 Docker 拉取 next 分支镜像：

# 拉取 NocoBase next 分支（包含 AI 员工并行功能）
docker run -d \
  --name nocobase-next \
  -p 13000:13000 \
  -e DB_DIALECT=postgres \
  -e DB_HOST=your-postgres-host \
  -e DB_PORT=5432 \
  -e DB_DATABASE=nocobase \
  -e DB_USER=nocobase \
  -e DB_PASSWORD=your-password \
  -e APP_ENV=next \
  nocobase/nocobase:next

# 如果只是本地试玩，可以用内置 SQLite 的简易模式
docker run -d \
  --name nocobase-next-dev \
  -p 13000:13000 \
  -e DB_DIALECT=sqlite \
  nocobase/nocobase:next

启动后访问 http://localhost:13000，进入后台的"工作流"模块，就能看到 AI 员工节点的配置入口。

注意：next 分支经过初步测试但可能存在部分不稳定行为，生产环境请等 main 分支合入后再升级。

并行度不是越高越好

多会话并行解决了吞吐问题，但也引入了新的工程考量：

API 限流是硬天花板

大模型 API 的限流通常按 Token/分钟（TPM）或请求/分钟（RPM）计算。并行度设得再高，超出配额就会被限流或报错。建议做法：

先测算单次 AI 员工调用的平均 Token 消耗。
用 配额 TPM / 单次消耗 Token ≈ 理论最大并行度 做粗算，然后留 30% 余量。

例如，你的 API 配额是 500K TPM，单次调用平均消耗 2K Token：

500000 / 2000 = 250 理论并行度
实际建议：250 * 0.7 ≈ 170 并行度上限

上下文窗口的内存开销

每个并行会话持有独立上下文，意味着内存占用是线性增长的。如果你的 AI 员工 prompt 很长或挂了大量工具描述，5 个并行会话可能就吃掉不少内存。在 NocoBase 的服务器配置里关注容器内存上限。

结果汇聚的顺序问题

并行会话完成时间不确定。汇聚节点需要处理"部分结果已到、部分还在跑"的情况。NocoBase 的 merge 节点支持超时等待和部分结果输出，建议根据业务容忍度配置 timeout_per_session——客服场景可以设短（15-30s），数据分析场景可以设长（60-120s）。

上手清单

如果你打算在项目中用 NocoBase AI 员工的并行能力，按这个顺序推进：

确认分支：开发/测试环境用 next，生产环境等 main 合入。
测算配额：算清楚你的大模型 API TPM/RPM 限制，据此设定 max_concurrent_sessions。
建好数据源：AI 员工要检索的知识库、订单表等集合，先在 NocoBase 里建好并验证查询可用。
从低并行度开始：先设 2-3 个并行会话跑通流程，观察延迟和错误率，再逐步上调。
监控汇聚节点：关注 merge 节点的超时率和部分结果比例，这直接反映并行调度的健康度。
留回退路径：并行出问题时能快速切回串行模式——NocoBase 工作流支持版本回退，配置变更前先保存快照。

NocoBase 作为开源平台，AI 员工的并行处理能力还在快速迭代中。当前 next 分支的功能已经可用，但细节和稳定性还在打磨。对于想提前验证场景的团队，现在正是介入的好时机——跑通原型，积累数据，等 main 合入后直接上生产。