AI智能体协作平台Agent Board：任务编排与MCP集成实战-程序员充电站

1. 项目概述：为AI智能体团队构建任务看板与编排中枢

如果你正在尝试构建一个由多个AI智能体（Agent）组成的协作团队，无论是基于OpenClaw、Claude还是其他大语言模型，你很快就会遇到一个核心挑战：如何让这些“数字员工”有序地协同工作，而不是各自为战、任务重复或流程中断？这正是Agent Board要解决的问题。它不是一个简单的待办事项列表，而是一个专为AI智能体团队设计的任务编排与协调平台，相当于为你的AI团队配备了一位永不疲倦的、精通项目管理的“虚拟项目经理”。

想象一下，你有一个内容创作团队：一个研究型Agent负责搜集资料，一个写作Agent负责撰写初稿，一个编辑Agent负责审核润色。如果没有协调，写作Agent可能会在资料不全时就开始工作，或者编辑Agent不知道初稿何时完成。Agent Board通过一个直观的看板（Kanban）界面和一套严谨的规则引擎，将这种协作流程自动化、可视化。它定义了任务从创建、分配、执行、审核到完成的完整生命周期，并确保任务间的依赖关系得到严格执行——比如，编辑任务必须等待写作任务完成后才能开始。更重要的是，它通过实时通信机制（如任务评论和Webhook）让Agent们能“对话”，并通过与Model Context Protocol（MCP）的原生集成，让Agent能像使用内置工具一样自然地管理任务，无需处理复杂的HTTP API调用。

对于AI应用开发者、自动化流程构建者以及研究多智能体系统的团队来说，Agent Board提供了一个开箱即用的编排层。它抽象了复杂的并发控制、状态管理和通信逻辑，让你能专注于定义智能体的业务能力，而将任务调度与协同的脏活累活交给它。接下来，我将深入拆解它的核心设计、如何上手集成，以及在实际部署中积累的一些关键经验。

2. 核心架构与设计哲学解析

Agent Board的架构选择体现了一种“务实而强大”的设计哲学。它没有追求使用最时髦的分布式数据库或微服务框架，而是通过精巧的设计，在保持极致简洁的同时，满足了多智能体协作场景下的核心需求：可靠性、实时性和易集成性。

2.1 无状态服务与文件存储的权衡

项目最引人注目的一个特点是它零外部数据库依赖，所有数据（项目、任务、审计日志）都存储在本地JSON文件中。这听起来似乎有些“复古”，但在特定场景下却是明智之举。

为什么选择JSON文件存储？首先，它极大地降低了部署和运维复杂度。你不需要额外安装、配置和维护PostgreSQL或Redis等服务，只需一个Node.js环境即可运行。这对于快速原型验证、边缘部署或在资源受限的环境中使用非常友好。其次，数据可读性强，你可以直接打开data/目录下的JSON文件查看或调试所有状态，甚至可以用Git进行版本管理，方便回溯任务流的历史变化。最后，它简化了备份和迁移，整个系统的状态就是几个文件，复制走即可。

如何保证并发安全？多智能体同时访问和修改任务状态是常态，文件系统通常不支持原子性的并发写操作，这会导致数据损坏。Agent Board通过两个关键机制解决了这个问题：

异步互斥锁（Async Mutex）：它为每个数据文件（如projects.json）维护一个锁。当一个请求（例如，Agent A移动任务）需要写入时，必须先获取该文件的锁。在此期间，其他试图修改同一文件的请求会被阻塞排队，直到锁被释放。这确保了同一时间只有一个操作能修改数据。
原子性写入：写入文件时，它并非直接覆盖原文件。而是先将新内容写入一个临时文件（如projects.json.tmp），写入成功后再通过文件系统的重命名操作（rename）原子性地替换原文件。即使写入过程中程序崩溃，原文件也完好无损。

注意：这种基于文件的存储方式非常适合中小规模、单机部署的智能体团队。如果你的智能体数量庞大（例如成千上万）、任务吞吐量极高，或者需要跨多台服务器部署以实现高可用，那么JSON文件的性能会成为瓶颈。在这种情况下，你可能需要考虑将其存储层替换为真正的数据库（如PostgreSQL），但其上层的业务逻辑（服务层）和API接口可以保持不变。

2.2 以MCP为核心的一等公民集成

Model Context Protocol (MCP) 是由Anthropic提出的一种协议，旨在让AI应用（如Claude桌面端）能够安全、标准化地访问外部工具和数据源。Agent Board将MCP提升到与REST API同等甚至更优先的地位，这是一个极具前瞻性的设计。

对于智能体开发者而言，MCP集成意味着什么？传统上，要让一个AI智能体使用某个服务，你需要：1) 在智能体代码中集成HTTP客户端库；2) 处理认证（如API密钥）；3) 解析复杂的JSON请求与响应。而通过MCP，这一切被简化为：在Claude Code或兼容MCP的客户端配置文件中，声明Agent Board服务器的启动命令。之后，智能体（如Claude）就能直接“看到”并调用board_create_task、board_my_tasks等工具，就像调用内置的思考或计算功能一样自然。智能体无需关心网络通信细节，它只需要用自然语言描述意图，MCP框架会负责工具调用。

这种设计带来的优势：

降低智能体复杂度：智能体代码无需包含任何与Agent Board通信的逻辑，变得更纯粹、更专注于业务。
提升开发体验：开发者可以在Claude桌面端直接与看板交互，测试任务创建、分配等流程，体验非常流畅。
更好的安全性：MCP连接通常建立在本地进程间通信或安全的SSE连接上，避免了API密钥在网络上明文传输的风险（尽管REST API也支持密钥认证）。

2.3 事件驱动与实时通信模型

多智能体协作不是批处理，需要近乎实时的响应。Agent Board采用了混合通信模型来满足这一需求。

心跳轮询（Pull模式）：这是最基本的方式。每个智能体定期（例如每30秒）调用GET /api/tasks?assignee=my-id&status=todo来检查是否有新任务分配给自己。这种方式实现简单，但存在延迟，且不必要地消耗资源。
Webhook推送（Push模式）：这是实现实时响应的关键。当发生特定事件时（如新任务被分配给某个智能体、任务状态变更、有新评论），Agent Board会主动向一个预设的端点（如OpenClaw的/hooks/agent）发送HTTP POST请求。这个请求会“唤醒”处于空闲或低功耗状态的智能体，使其立即开始处理任务。为了确保安全，Webhook支持HMAC-SHA256签名，接收方可以验证消息确实来自可信的Agent Board服务器，防止伪造请求。
任务评论线程（异步通信）：智能体之间可以通过在任务下添加评论进行对话。例如，研究Agent可以留言：“已找到相关资料，附在输出中”。当一条评论被添加时，会触发一个comment.add类型的Webhook通知当前的任务负责人，从而实现基于上下文的异步协作。

这种“推送为主，轮询为辅”的模型，在保证实时性的同时，也兼顾了系统的可靠性和智能体实现的灵活性。

3. 从零开始部署与核心功能实操

让我们抛开理论，动手搭建一个属于你自己的智能体协作平台。我将以与OpenClaw智能体框架集成为例，展示最核心的流程。

3.1 环境准备与快速启动

假设你已经在开发机上安装了Node.js（版本18或更高）和Git。

# 1. 克隆仓库并安装依赖 git clone https://github.com/quentintou/agent-board.git cd agent-board npm install # 2. 构建TypeScript代码 npm run build # 3. 使用自定义端口和数据目录启动（可选） # 默认端口是3456，数据存在./data目录 node dist/index.js --port 8080 --data /path/to/your/data # 或者直接使用npm脚本启动（使用默认配置） npm start

启动成功后，打开浏览器访问http://localhost:3456（或你指定的端口），你应该能看到内置的看板仪表盘。同时，REST API服务也在同一端口下运行，基础路径是/api。

3.2 创建第一个项目与任务流

我们通过API来模拟一个简单的智能体工作流：一个“研究Agent”完成任务后，自动创建一个新任务给“写作Agent”。

步骤1：创建项目

curl -X POST http://localhost:3456/api/projects \ -H "Content-Type: application/json" \ -d '{ "name": "Q3产品市场分析报告", "owner": "strategy-team", "description": "由AI团队协作完成的市场趋势与竞品分析报告。" }'

保存返回的projectId，例如proj_abc123。

步骤2：为“研究Agent”创建初始任务这个任务有一个特点：它定义了nextTask，意味着当它完成时，会自动创建后续任务。

curl -X POST http://localhost:3456/api/tasks \ -H "Content-Type: application/json" \ -d '{ "projectId": "proj_abc123", "title": "搜集Top 5竞品Q3动态与财报信息", "assignee": "research-agent", "priority": "high", "tags": ["research", "competitor"], "requiresReview": false, "nextTask": { "title": "基于研究数据起草报告摘要", "assignee": "writer-agent", "priority": "medium", "tags": ["writing", "summary"] } }'

这个请求创建了第一个任务，并预先定义好了它的后继任务。注意，nextTask的配置是嵌套在创建请求中的，非常简洁。

步骤3：模拟研究Agent领取并完成任务研究Agent通过查询自己的待办任务开始工作：

curl "http://localhost:3456/api/tasks?assignee=research-agent&status=todo"

找到任务后，它将其状态移动到doing表示开始处理：

curl -X POST http://localhost:3456/api/tasks/<task_id>/move \ -H "Content-Type: application/json" \ -d '{"column": "doing"}'

（假设研究Agent完成工作后）它将任务标记为done：

curl -X POST http://localhost:3456/api/tasks/<task_id>/move \ -H "Content-Type: application/json" \ -d '{"column": "done"}'

步骤4：观察任务自动衔接当第一个任务被移动到done列时，Agent Board的服务层会自动触发一个动作：根据nextTask的配置，创建一个新的任务。这个新任务的title、assignee等属性均来自预设，并且其dependencies字段会自动指向已完成的前置任务ID。此时，写作Agent（writer-agent）的待办任务列表里就会出现“基于研究数据起草报告摘要”这个新任务。整个流程无需任何外部编排脚本介入。

实操心得：nextTask功能非常适合构建线性的、确定的流水线。但对于复杂的、有分支的工作流（例如，研究结果如果是正面的走A流程，负面的走B流程），仅靠nextTask无法实现。这时，你需要一个更外部的“指挥者”智能体，或者利用任务的output字段结合Webhook，由接收Webhook的服务来决定创建何种后续任务。

3.3 配置OpenClaw智能体进行双向通信

要让OpenClaw中的智能体真正“活”起来，与看板互动，需要完成两端配置。

在Agent Board端配置Webhook：这是为了让Agent Board能主动通知OpenClaw。

# 启动Agent Board时设置环境变量，或写入systemd服务文件 export OPENCLAW_HOOK_URL=http://localhost:18789/hooks/agent export OPENCLAW_HOOK_TOKEN=your_openclaw_hooks_secret_token node dist/index.js

OPENCLAW_HOOK_TOKEN必须与OpenClaw网关中配置的Webhook令牌一致，否则通知会被拒绝。

在OpenClaw智能体端配置心跳检查：每个智能体需要定期检查看板。在其工作目录的HEARTBEAT.md文件中，可以添加如下指令：

### 任务检查 每隔30秒检查一次看板，看看是否有分配给我的新任务或需要回复的评论。 ```bash #!/bin/bash ASSIGNED_TASKS=$(curl -s -H "X-API-Key: $AGENTBOARD_API_KEY" \ "http://localhost:3456/api/tasks?assignee=$(hostname)&status=todo") if [ "$(echo $ASSIGNED_TASKS | jq '. | length')" -gt 0 ]; then echo "有新的待办任务，开始处理。" # 这里可以解析任务详情，并调用智能体的主逻辑 fi

注意，上面的脚本示例中使用了`$AGENTBOARD_API_KEY`，这需要在智能体的环境变量中配置，并与Agent Board启动时设置的`AGENTBOARD_API_KEYS`匹配。 **通信流程闭环：** 1. 项目经理（或另一个智能体）通过API/MCP在看板上创建了一个高优先级任务，并分配给“research-agent”。 2. Agent Board的`task.create`事件触发，向`OPENCLAW_HOOK_URL`发送一个签名的Webhook， payload中包含任务详情和分配对象。 3. OpenClaw网关收到Webhook，验证令牌后，立即向名为“research-agent”的智能体会话发送一个信号，唤醒它。 4. 被唤醒的“research-agent”执行其`HEARTBEAT.md`中的脚本，调用Agent Board API获取任务详情，并开始工作。 5. 工作过程中，“research-agent”可以通过添加评论的方式与任务创建者或其他相关方异步沟通。 6. 任务完成后，“research-agent”将任务状态改为`done`。如果设置了`nextTask`，则新的任务被自动创建并可能触发新的Webhook，唤醒下一个智能体。 ## 4. 高级功能详解与配置指南 掌握了基础流程后，我们深入看看那些让Agent Board在复杂场景下依然可靠的高级特性。 ### 4.1 有向无环图（DAG）依赖管理 这是实现复杂工作流的核心。一个任务可以依赖多个前置任务，只有所有前置任务都处于`done`状态时，该任务才能被移出`backlog`或`todo`列（通常意味着可以开始执行）。 **如何设置依赖？** 在创建或更新任务时，通过`dependencies`字段指定一个任务ID数组。 ```json { "title": "生成最终报告", "assignee": "editor-agent", "dependencies": ["task_research_id", "task_writing_id"] }

在这个例子里，“生成最终报告”任务依赖于研究和写作两个任务。在界面上，你会看到该任务卡片上可能有明显的“阻塞”标识。通过APIGET /api/tasks/:id/dependencies可以清晰地看到它正在等待哪些任务。

系统如何防止死锁？Agent Board在服务层内置了循环依赖检测。当你试图设置依赖关系时（例如，任务A依赖任务B，同时又试图让任务B依赖任务A），系统会拒绝这个操作并返回错误。这防止了因为依赖成环而导致所有相关任务永远无法开始的死锁情况。

注意事项：依赖检查只在任务尝试离开backlog/todo列时发生（例如，移动到doing）。一旦任务进入doing状态，依赖关系就不再被检查。这意味着，理论上你可以通过API强行将一个已被阻塞的任务状态改为doing，但这违背了设计初衷。最佳实践是始终通过标准的POST /move接口来移动任务，以享受完整的依赖和关卡校验。

4.2 质量关卡与自动重试

质量关卡（requiresReview）：对于某些关键任务，你可能不信任单个智能体的输出，需要引入审核环节。在创建任务时设置"requiresReview": true，则该任务在完成后不能直接进入done列，而必须进入review列。必须由另一个具有审核权限的角色（可能是另一个智能体，也可能是人类）将其从review移动到done。这为工作流增加了质量控制点。

自动重试（maxRetries）：智能体处理任务可能因临时性错误（如网络超时、API限流）而失败。在任务中设置"maxRetries": 3，当该任务被移动到failed列时，系统会自动将其状态重置为todo，并递增重试计数器。同时，系统会在任务评论中自动添加一条记录，说明这是第几次重试。这对于构建健壮的自动化流程至关重要，避免了因瞬时故障导致整个流程停滞，需要人工介入的情况。

4.3 安全与审计

API密钥认证：在生产环境中，强烈建议启用API密钥认证。通过环境变量AGENTBOARD_API_KEYS设置，格式为key1:agentId1,key2:agentId2。启用后，所有REST API请求必须在Header中携带X-API-Key: your-key。服务器会验证密钥，并将操作关联到对应的agentId记录到审计日志中。这实现了基本的权限隔离和操作溯源。

完整的审计追踪：所有通过REST API或MCP接口对数据进行的变更操作（创建、更新、删除、移动、评论）都会被记录到audit.jsonl文件中。每条记录包含时间戳、执行者（agentId或API密钥标识）、操作类型、影响的资源ID以及变更前后的数据快照（对于更新操作）。这是一个只追加的日志，你可以通过GET /api/audit接口查询，这对于调试复杂的工作流、分析智能体行为或满足合规性要求非常有价值。

Webhook签名验证：如果你配置了AGENTBOARD_WEBHOOK_SECRET，那么所有由Agent Board发出的Webhook请求都会包含一个X-AgentBoard-Signature头，其值是使用HMAC-SHA256对请求体和时间戳计算得出的签名。接收方（如OpenClaw网关或你的自定义服务）可以使用项目提供的shared/verify-webhook.sh脚本或自行实现验证逻辑，来确保请求确实来自可信的Agent Board实例，且未被篡改。

5. 生产环境部署与运维考量

将Agent Board用于实际项目时，需要考虑以下几个运维层面的问题。

5.1 性能与扩展性

如前所述，基于JSON文件的存储方式在任务和项目数量激增时可能会遇到性能瓶颈，主要体现在：

文件读写延迟：每次API调用都可能涉及读取和写入整个JSON文件。当文件体积达到MB级别时，IO延迟会变得明显。
锁竞争：高并发下，多个智能体同时请求修改同一个项目下的任务，会因为互斥锁导致请求排队。

应对策略：

分而治之：根据业务逻辑，将智能体团队划分到不同的项目中。因为锁是文件级别的，不同的项目对应不同的数据文件，可以并行处理。
升级存储层：如果性能成为主要瓶颈，可以考虑修改store.ts模块，将其后端从文件系统切换到数据库。由于业务逻辑（services.ts）与存储层是分离的，这个替换是可行的。SQLite是一个轻量级的升级选择，而PostgreSQL则能提供更强的并发能力和查询功能。
前端优化：仪表盘默认每5秒轮询一次服务器以更新看板状态。在任务量很大的看板上，这会给服务器带来不必要的负载。可以考虑适当增加轮询间隔，或者更理想的是，为仪表盘添加WebSocket支持，实现真正的服务器推送更新。

5.2 高可用与数据备份

高可用：当前的单机部署模式存在单点故障。如果运行Agent Board的服务器宕机，整个智能体协作系统将瘫痪。要实现高可用，需要更复杂的架构，例如：

使用负载均衡器后面部署多个Agent Board实例。
但这要求存储层必须是共享的（如数据库），而不是本地文件。
或者，将Agent Board设计为无状态服务，将会话和状态存储在外部Redis中。这属于较大的架构改动。

数据备份：虽然Agent Board有“写前自动备份”机制（在修改文件前，自动将旧文件复制为.bak后缀的备份，最多保留50个），但这不能替代系统级的备份策略。

定期快照：应对data/目录进行定期备份（例如，使用cronjob执行rsync或tar）。
版本控制：可以考虑将data/目录纳入Git仓库，但要注意敏感信息（如API密钥可能出现在审计日志中）。更好的做法是使用git-crypt或git-secret等工具对敏感数据进行加密后再提交。

5.3 监控与告警

一个健康的智能体系统需要监控。

服务健康：使用GET /api/health端点作为存活探针，集成到Kubernetes或Docker的健康检查中。
任务堆积：通过GET /api/stats接口可以获取全局统计信息，包括每个智能体的任务数量、平均完成时间等。你可以编写一个监控脚本，定期检查是否有智能体的todo任务数超过阈值，或者是否有任务在doing状态停留时间过长（“卡住”的任务），并通过邮件、Slack等方式告警。
审计日志分析：定期分析audit.jsonl，可以发现异常模式，例如某个智能体频繁失败、任务在review阶段停留过久等。

5.4 容器化部署示例

使用Docker可以简化依赖管理和部署。以下是一个简单的Dockerfile示例：

# 使用官方Node.js镜像 FROM node:22-slim AS builder WORKDIR /app COPY package*.json ./ COPY tsconfig.json ./ COPY src/ ./src/ RUN npm ci && npm run build FROM node:22-slim WORKDIR /app ENV NODE_ENV=production # 复制生产所需的文件 COPY --from=builder /app/package*.json ./ COPY --from=builder /app/dist/ ./dist/ COPY --from=builder /app/dashboard/ ./dashboard/ COPY --from=builder /app/templates/ ./templates/ RUN npm ci --production # 创建数据卷挂载点 VOLUME /app/data EXPOSE 3456 # 启动命令，允许通过环境变量覆盖参数 CMD ["node", "dist/index.js", "--port", "3456", "--data", "./data"]

构建并运行：

docker build -t agent-board . docker run -d \ -p 3456:3456 \ -v /path/to/host/data:/app/data \ -e OPENCLAW_HOOK_TOKEN="your-token" \ --name agent-board \ agent-board

6. 常见问题排查与实战技巧

在实际集成和使用过程中，你可能会遇到一些典型问题。这里记录了我踩过的一些坑和对应的解决方案。

6.1 Webhook通知未触发

症状：在看板上创建或分配了任务，但对应的OpenClaw智能体没有被唤醒。

排查步骤：

检查Agent Board日志：启动Agent Board时，确保没有与Webhook相关的错误。查看控制台输出，确认OPENCLAW_HOOK_URL和OPENCLAW_HOOK_TOKEN环境变量已正确加载。

验证网络连通性：从运行Agent Board的机器上，尝试手动curl OpenClaw的Webhook端点，看是否能通。

curl -X POST http://<openclaw-host>:18789/hooks/agent \ -H "Authorization: Bearer your-token" \ -H "Content-Type: application/json" \ -d '{"test": "payload"}'

检查OpenClaw网关配置：确认OpenClaw网关的Webhook配置中，令牌与Agent Board使用的OPENCLAW_HOOK_TOKEN完全一致（包括大小写）。
查看Agent Board审计日志：调用GET /api/audit?limit=10，查看最近的操作是否记录了Webhook发送事件。如果事件被记录了但智能体没醒，问题可能出在网络或OpenClaw端；如果事件根本没记录，则说明Agent Board的业务逻辑没有触发Webhook（例如，任务创建时未分配assignee？）。

6.2 任务无法移动到“进行中”

症状：尝试将任务从todo移动到doing时，API返回错误。

可能原因及解决：

依赖未满足：这是最常见的原因。错误信息通常会明确指出是哪些前置任务尚未完成。你需要去将这些阻塞任务先完成。
任务已不在todo列：只有状态为backlog或todo的任务才能被移动到doing。检查任务当前状态。
并发冲突：另一个请求可能刚刚修改了此任务或它的依赖项。重试一下操作通常可以解决。

6.3 MCP工具调用失败

症状：在Claude Desktop中配置了MCP服务器，但Claude无法识别或调用Agent Board的工具。

排查步骤：

确认MCP服务器运行正常：单独运行npm run mcp，查看是否有错误输出。确保使用的Node版本符合要求。
检查Claude配置：Claude Desktop的MCP服务器配置（通常是claude_desktop_config.json）路径必须正确指向编译后的mcp-server.js文件，并且args中的--data路径要存在且有读写权限。
查看MCP服务器日志：MCP通信通过stdio进行，日志会输出到控制台。在启动MCP服务器的终端里，查看当你在Claude中尝试使用工具时，是否有相应的请求和响应日志。
版本兼容性：确保你使用的@modelcontextprotocol/sdk版本与Claude Desktop兼容。查看项目package.json和Anthropic的MCP文档。

6.4 数据文件损坏或丢失

症状：服务启动失败，或读取项目/任务时出现JSON解析错误。

恢复方法：

利用自动备份：Agent Board会在每次写操作前备份原文件，备份文件位于同一目录，后缀为.bak、.bak1…….bak49。找到最新的可用备份文件，将其重命名回原文件（例如，将projects.json.bak3重命名为projects.json）。
手动修复JSON：如果备份也不可用，可以尝试手动编辑JSON文件。由于是标准JSON格式，你可以使用jq工具来验证和格式化文件：jq . corrupted-file.json > fixed-file.json。注意，这可能会丢失最后一次写入的数据。
预防措施：务必建立定期的、自动化的data/目录备份策略。

6.5 提升协作效率的实战技巧

善用标签（Tags）：为任务打上诸如bug、feature、urgent、design等标签。这样，智能体或你通过API过滤任务时（?tag=urgent）可以快速定位某一类工作。你也可以让负责不同领域的智能体只关注带有特定标签的任务。
优先级（Priority）的动态调整：priority字段（high, medium, low）不仅用于排序。你可以配置Webhook接收服务，当有high优先级任务创建时，立即中断某个智能体当前的低优先级任务，转而处理这个高优先级的任务。
利用评论进行上下文传递：当一个智能体完成任务时，除了将任务标记为done，强烈建议它也在评论中附上关键产出、结论或下一步建议的链接。这为后续处理此任务链的智能体提供了宝贵的上下文，减少了重复工作。
模板化项目创建：对于重复性的工作（例如，每周的数据分析报告、每次的产品发布检查清单），预先在templates/目录下创建JSON模板。然后通过POST /api/projects/:id/from-template接口一键生成包含所有标准任务的项目，极大提升初始化效率。

Agent Board作为一个开源项目，其价值在于它提供了一个清晰、可扩展的多智能体协作范式。你可以直接使用它来管理你的AI团队，也可以将其核心思想——基于看板的状态管理、DAG依赖、事件驱动通信——借鉴到你自己的系统中。随着智能体能力的不断增强，这类编排工具将成为连接各个“AI专家”、构建复杂自动化工作流的不可或缺的粘合剂。