做业务系统的朋友应该都有同感：大模型能力再强，一旦落到具体业务里，常常会变成“演示很惊艳，生产跑不动”。问题通常不在模型本身，而在业务需要的是一个能拆解任务、调用工具、互相协作、还能被业务人员盯着的“AI 团队”，而不是孤零零的聊天机器人。最近我把手头这套多智能体框架和行业工作台整理成了独立项目，起名 MyCoWork，并把它开源了出来。简单说，它是一套用于搭建和管理多智能体协作流程的运行时，加上一批针对行业场景预置的工作台资产，让业务系统可以直接“招聘”一支 AI 团队上岗干活。这篇文章我就把这些年的实践思路、架构取舍、落地步骤和踩坑记录都摊开来讲。
1. 为什么需要给业务装上 AI 团队：从单模型到多智能体
1.1 单个模型能力再强，也扛不住一个完整业务岗位
先从一个很常见的现象说起。很多人早期接入大模型，都是把“一个模型”当成“一个员工”来用：让大模型读用户问题，直接给答案。这在知识问答类场景没有问题，但一旦落到真实业务链路里，就会露馅。
我举个例子。某客服团队想用大模型自动处理售后工单。刚开始直接拿一个模型调接口，用户说“我买的东西没收到，要退款”，模型确实能生成一段很礼貌的回复。可点到后台一看，订单系统根本查不到这个用户，也没法判断“没收到”是物流丢件还是地址填错，模型写的退款方案没有任何依据。这类失败不是模型笨，而是业务处理本身就是一套流程：先核实身份，再查订单状态，再判断售后策略，然后才能生成回复。把这套流程硬塞到一次模型调用里，既超出了模型的上下文能力，也超出了单次对话能承载的信息量。
所以我在 MyCoWork 里的第一个设计判断是：不能拿模型去模仿整个岗位，而要让模型只承担岗位里的“思考环节”。查询订单、修改状态、读知识库、发通知，这些交给工具；判断该不该退款、该走哪条SOP、如何安抚用户，才交给模型。模型负责推理，流程负责正确性，工具负责执行力。
1.2 多智能体协作不是堆模型，而是拆岗位
多智能体这个说法这两年很火，但很多人第一反应是：调多个模型，让它们互相聊天，是不是就能把问题解决得更深？我试过早期那种“让几个Agent自由对话”的玩法，结论是：热闹但不可控。Agent们聊得欢，业务流程该卡还是卡，甚至因为互相传递幻觉，把本来能解决的问题搞得更乱。
后来我把思路换了一下：多智能体不是“多模型”，而是“多岗位”。一个真实的业务团队里，有分析师、执行者、质检员、审批人，每个人都有自己的职责边界和工作产物。多智能体系统只是把这种组织方式搬到了程序里。
MyCoWork 里，每个 Agent 都是一个独立的职能单元，拥有自己的系统提示词、工具集、记忆空间和输出规范。它们之间通过结构化消息协作，而不是直接把整段对话历史甩给另一个 Agent。比如处理一笔客诉，需求分析 Agent 负责把用户原话转成结构化问题；方案 Agent 根据问题清单生成处理建议；执行 Agent 调订单和售后接口落地操作；质检 Agent 再检查一遍操作是否符合规则。每个环节都有单一职责，出了问题也能精确回溯到某个岗位。
这里有一个很关键的经验：能拆成岗位的任务才适合多智能体，如果业务本身只是一问一答，强行上多智能体，只会白白增加延迟和成本。多智能体的价值在于把复杂流程分解成可校验、可审计、可并行的小步骤，而不是让模型显得更聪明。
1.3 行业工作台是 AI 团队落地业务的最后一块拼图
Agent 本身跑得再好，如果业务人员没有一个操作台，这套系统仍然只停留在 API 层面。开发人员可以天天写代码调 Agent，但业务运营、客服主管、质检专员不可能每个人都会看日志。他们要的是：能看到任务跑到哪一步了，谁在处理，为什么这个单子被喊停，出了问题找谁复审。
这就是行业工作台的价值。MyCoWork 把通用的多智能体运行时和行业工作台分开：运行时解决 Agent 的创建、编排、工具接入和调度，工作台解决业务场景的模板、数据连接器、人工节点和审计界面。面向客服，就有客诉处理、工单质检、话术生成几种预置流程；面向运营，就有活动方案拆解、物料清单生成、竞品信息汇总等一套组合。
我把行业工作台理解为“给 AI 团队配了办公桌”。没有办公桌，团队成员再能干，也坐不进业务流程。有了办公桌，业务人员就能像用普通管理系统一样，查任务、点审批、看结果，而不是被大模型的黑盒反馈搞得手足无措。这也是 MyCoWork 开源版本里我最想强调的部分：多智能体和行业工作台必须一起给，才算真正给业务装上了一支 AI 团队。
2. MyCoWork 整体架构与核心设计思路
2.1 把 Agent 定义成“岗位”，而不是“聊天机器人”
很多框架把 Agent 定义得很模糊，似乎只要有大模型、有工具，就是一个 Agent。MyCoWork 里我更倾向于用“岗位说明书”的方式来定义 Agent。一个岗位必须包含：职责范围、工作输入、工作输出、可用工具、行为边界、质量要求。把这些写到配置文件里，Agent 的行为才会稳定。
我通常用一份 YAML 描述一个 Agent，看起来像这样：
agents: - name: demand_analyst display_name: 需求分析师 role_description: | 你负责把用户的原始问题解析为结构化任务。 你需要判断问题类型、提取关键实体、标注紧急程度。 不要执行任何写操作，不要给出处理建议。 model: provider: default model_name: fast-chat temperature: 0.1 max_tokens: 2048 tools: - crm_user_query - order_status_query memory: type: short_term ttl: 3600 input_schema: type: object properties: user_message: type: string output_schema: type: object properties: issue_type: type: string entities: type: array priority: type: string这份配置最关键的不是模型参数，而是三个东西：role_description、tools、output_schema。role_description 决定了模型以什么视角思考；tools 决定了它能做什么；output_schema 决定了它交出来的工作成果长什么样。三者一起约束，Agent 才不会跑偏。
在实际使用中我会把 temperature 尽量调低，尤其是需求分析这类需要稳定输出的岗位。写作、创意类的Agent 可以把 temperature 调高一些，但业务执行链路上的 Agent 尽量追求确定性。
2.2 调度器、记忆与协作协议，三个容易忽视的底层件
Agent 定义好了以后，背后还有三个不常在界面上露面的组件，却决定了整个系统能不能稳定跑。
第一个是调度器。MyCoWork 里的调度器按照流程定义把任务发给对应 Agent。流程可以是顺序的，可以是并行的，也可以中途挂起等待人工审批。调度器维护每个任务的当前状态、重试次数、超时时间，并把异常路径处理后的事件推送给工作台。早期我为了追求灵活性，让 Agent 之间直连，结果一崩全崩，后来所有消息都改成经过调度器中转，问题就清晰了很多。
第二个是记忆。Agent 之间的记忆必须做隔离。MyCoWork 给每个 Agent 配了三类记忆：短期对话记忆、业务实体会话记忆和团队共享记忆。短期记忆存在于单个任务生命周期，任务结束就清理；业务记忆保存订单号、用户ID、处理状态这类结构化信息；共享记忆存放可以复用的规则与结论。共享记忆不是存放全部上下文，而是只存可复用的结论，避免不同 Agent 互相污染。
第三个是协作协议。Agent 之间传消息需要一套统一的“工单”格式，我一般定义成：
{ "task_id": "task_20250115_001", "parent_task_id": "root_task_009", "from": "demand_analyst", "to": "solution_agent", "status": "pending", "message_type": "task_result", "payload": { "issue_type": "delivery_delay", "order_id": "SO20250115001", "priority": "high" }, "trace": ["demand_analyst"] }这个格式的核心作用是让任务可追踪。每个 Agent 只拿自己需要的字段，不会看到别的 Agent 的中间思考过程。很多“上下文串台”的问题，源头就是过度传递信息。协作协议里必须规定“最小必要信息”原则。
2.3 行业工作台里的资产沉淀逻辑
行业工作台听起来很重，其实核心就是“资产沉淀”。通用运行时是生产工具的底层能力，而行业工作台的价值在于，把一个领域里反复用到的流程、规则、提示词、工具连接器提前做好。
我做一个客服工作台时，会把常用资产分成五类：流程模板、Agent角色、工具连接器、规则集、质检指标。流程模板解决“这个行业常见的处理链路是什么”；Agent角色解决“链路里需要哪些岗位”；工具连接器解决“怎么连订单、CRM、工单系统”；规则集解决“哪些事不能做，哪些话不能说”；质检指标解决“怎么衡量AI干得好不好”。
每个行业的工作台不是从零做起的。MyCoWork 开源仓库里带了一个通用的基础工作台，以及客服和营销两个示例行业包。基础工作台负责任务可视化、人工审批、日志检索、Agent状态监控；行业包负责把预置的流程和角色装进去。实际落地时，把行业包的模板复制出来改一改，比从零配置快很多。
在资产沉淀上我有一条心得：把每一次成功处理的任务沉淀成案例。案例用来做两个事情，一是后续相似任务可以检索出来作为参考，二是可以拿真实案例反向优化流程模板。这样工作台会越用越“懂”这个行业，而不只是空壳界面。
3. 从零搭一个业务级AI团队：完整实操过程
3.1 部署准备：仓库、依赖与模型配置
先交代一下环境。MyCoWork 的运行时是一个服务端应用，本地开发只需要一个 Python 环境和容器运行时。代码仓库拉下来以后，先装依赖，再配置数据库和模型供应商。
我的建议是直接把项目放在容器里跑，因为依赖版本锁定得比较干净，也能避免本地环境互相污染。容器起来以后，需要有一个关系数据库存储任务、流程定义和日志，另外要有一个向量库用来做案例检索和共享记忆。没有向量库也能跑，只是案例沉淀功能会被降级。
模型供应商的配置通过环境变量完成，不同家的模型接口在 MyCoWork 里被抽象成了统一的 provider。我通常会配两类模型：一类是响应快、成本低的轻量模型，用来做需求分析、信息提取、分类等任务；另一类是能力强、回答质量高的模型，用来做方案生成、内容创作等任务。同一个模型可以服务多个 Agent，但不同 Agent 要用不同的 temperature 和 max_tokens。
启动时执行：
# 安装基础依赖 pip install -r requirements.txt # 初始化数据库 python manage.py migrate # 启动运行时服务 python manage.py runserver 0.0.0.0:8080 # 启动调度器进程 python worker.py --queue default这里注意，调度器和工作台界面最好分开跑。调度器是后台常驻进程，界面服务是给业务人员访问的，两者混在一起会导致界面操作卡顿。我第一次部署时图省事，一个进程全包，结果任务一多，界面几十秒才打开，后来拆开就好多了。
3.2 用配置创建第一个智能体
部署完成后，创建 Agent 不需要写代码，我直接在 YAML 配置目录里新建一个文件即可。下面是一个“方案 Agent”的配置，用于在需求分析完成后生成处理方案：
agents: - name: solution_agent display_name: 方案生成师 role_description: | 你是资深售后处理专员，根据需求分析结果生成可执行的处理方案。 方案必须包含：退款/补发/维修/安抚话术四类选项中的一种或多种。 必须说明每一步需要调用哪个工具，不能编造订单信息。 model: provider: default model_name: strong-chat temperature: 0.3 tools: - refund_policy_query - logistics_tracking - compensation_rule_query memory: type: business key_fields: ["order_id"] output_schema: type: object properties: action: type: string enum: ["refund", "resend", "repair", "compensate", "manual_review"] reason: type: string steps: type: array review_required: type: boolean给 Agent 配置工具的时候，我强调的是“够用就好”。方案师只需要读策略和物流，就不要给它改订单状态的工具。每个 Agent 能调用的工具必须在配置里显式列出，这比在代码里判断权限要直观得多。
新 Agent 创建后，在系统启动时会自动注册。之后可以到工作台上给它做一次“上岗测试”，也就是用几条历史数据跑一遍，看输出是否符合预期。不要跳过这一步，我见过太多 Agent 配置完看着没问题，一跑真实数据就发现输出格式对不上。上岗测试成本很低，下场救火成本很高。
3.3 编排一条业务流：从“客诉进来”到“处理完成”
Agent 配好了，就要把它们串成流程。MyCoWork 里流程定义也是配置文件。我拿“客诉自动处理”流程来演示，这是电商类业务最常见的一条链路。
流程的逻辑是：收到客诉消息后，先做需求分析，再生成处理方案，金额低于某个阈值直接执行，高于阈值或命中敏感规则则挂起等待人工审批，最后质检 Agent 对执行结果做复核。
workflows: - name: complaint_auto_process trigger: type: webhook path: /api/trigger/complaint nodes: - id: start type: start next: analyze - id: analyze type: agent_task agent: demand_analyst next: generate_solution - id: generate_solution type: agent_task agent: solution_agent next: policy_check - id: policy_check type: rule condition: > payload.get('amount', 0) < 200 and payload.get('risk_level') == 'low' true_next: execute false_next: manual_review - id: execute type: agent_task agent: exec_agent next: quality_check - id: manual_review type: manual assignee: "order_support_team" next: execute - id: quality_check type: agent_task agent: review_agent next: end - id: end type: end从这份配置能看出，流程定义里最关键的动作是 policy_check。它不是 Agent，而是一条确定性规则。我把这类不能再让模型“自由发挥”的判断全部写成规则，比如金额阈值、敏感词命中、风险等级。Agent 可以提出建议，但最终规则必须确定。
实际跑下来，这样的流程比全交给 Agent 可靠得多。用户消息进来，几秒钟分析完，再几秒生成方案，小额低风险单子直接自动执行，高风险单子自动转人工。工作台上能看到每一步的状态和负责人，出了问题直接定位到节点。
3.4 通过接口把工作台接进现有业务系统
行业工作台不可能独立于业务系统存在，必须接入现有系统。MyCoWork 的触发方式主要有三种：Webhook、消息队列和数据库变更监听。
Webhook 是最简单的。比如客服系统收到新工单时，调用一个 HTTP 接口，把工单内容发过来；MyCoWork 生成任务后，把状态回调回去。消息队列适合高吞吐场景，比如每分钟进来几万条消息，Webhook 压力太大，就发到队列里让调度器消费。数据库变更监听则适合已经有业务中台、不想改上游代码的情况，监听订单表的新增字段，自动触发对应流程。
接入时有一个安全底线：Agent 执行写操作时，不要让它直接连生产库改数据。MyCoWork 的工具层只调用业务系统暴露的接口，这样权限、审计、幂等都可以在接口层做。比如执行退款，工具调用的应该是售后系统的退款接口，而不是让 Agent 发一条 SQL 去 update 订单表。让 Agent 直接操作数据库，等于把炸弹交到了它手里，哪怕它通常很听话。
接入完成后，我还会做一次“权限边界自测”：给 Agent 发一个包含越权指令的测试任务，看它是否尝试调用未被授权的工具。这一条建议放在上线检查清单里，非常值得做。
4. 实战踩坑记录与问题排查清单
4.1 Agent 之间上下文“串台”，业务结果完全不可用
第一次把多个 Agent 串起来跑测试时，我发现一个很有意思的 bug：需求分析师明明只负责解析用户问题，结果它的回复里出现了方案 Agent 才应该写的退款建议。后来查日志发现，我在流程图里图省事，把需求分析 Agent 的输出结果“完整”地塞给了方案 Agent，方案 Agent 读完感觉前面的建议不够好，自己又写了一遍，反而把标准处理流程带偏了。
这个问题的根源是上下文污染。多个 Agent 共享了完整历史，每个 Agent 都倾向于在自己环节里“多干一点”，结果职责边界被打破。解决办法很简单：Agent 之间传递信息必须经过字段抽取，每个下游 Agent 只接收自己需要的那几个字段，而不是接收一大段自然语言输出。后来我在协作协议里强制要求消息体必须符合各自声明的 input_schema，任何多余字段都会被调度器过滤掉，这一类问题基本消失。
4.2 工具权限太宽，AI 把测试库订单改成了“已退款”
这个坑是我故意给测试环境埋的，结果真的踩中了。某个执行Agent 配置工具时，我把“订单查询”“订单备注”“订单修改”“退款申请”全都挂了上去。然后模拟测试时，需求分析 Agent 误判了用户情绪，执行 Agent 为了“让用户满意”，自动把一个不需要退款的订单改了状态。
翻日志发现，执行 Agent 的逻辑其实没错，它是按流程来的，问题是它手里的权限太宽了。诊断结果是：给执行 Agent 的工具必须按“岗位最小权限”配置，能查不查全部，能读不写，写操作必须走额外校验。我把退款、改状态这类操作单独拎出来，加了一层人工确认节点，高风险操作无论 Agent 判断多么自信，都必须有业务人员在“工作台”上点确认。这个改动之后，误操作比例降到了零。
4.3 模型偶尔“罢工”，需要确定性兜底
大模型的表现再稳定，也会有超时、拒绝回答、输出格式错乱的时候。MyCoWork 在调度层加了三道兜底：第一道是输出校验，Agent 跑完后用 JSON Schema 校验，不合规直接让同一个 Agent 重试一次；第二道是重试衰减，连续两次失败就放弃自动重试，不会让模型陷入死循环；第三道是人工升级，如果这个节点是高风险操作，失败后直接把任务转入人工队列，让业务人员接手。
def process_agent_result(result, agent_config): if not validate_schema(result, agent_config.output_schema): return Retry(count=1, reason="schema_validation_failed") if result.risk_level == "high" and result.needs_manual_check: return Escalate(assignee="order_support_team") return Continue(result)这个兜底逻辑建议写进每个流程节点，不要想着模型永远正确。模型的不确定性不是 bug，是特性。调度器要做的就是预判这种不确定性，并且把失败路径设计好，让系统在任何情况下都能给业务一个明确交代。
4.4 多智能体跑起来后，性能与成本双双失控
多智能体的成本不是“一个Agent调一次模型”那么简单。一条业务流里五六个 Agent，每个 Agent 两三次重试，最后账单一算，比原来单模型接口贵好几倍。性能上也有类似问题，两个 Agent 之间串行跑，每个都要等完整响应，整体链路延迟累加起来很吓人。
我的处理方式分三块。第一，给每条流程设置“最大模型调用预算”，超过预算自动降级到简单模型或人工处理。第二，把不依赖上下文的 Agent 设成并行节点，比如同时跑需求分析和用户历史查询，节省整体时间。第三，对重复性任务做结果缓存，同一个用户、同一类问题在一定时间窗口内直接复用历史结论，不是每次都要重新推理。
以下是我之前整理的问题速查表：
| 现象 | 可能原因 | 排查建议 |
|---|---|---|
| 几个Agent互相传错信息 | 上下文串台 | 检查消息体字段，启用input_schema过滤 |
| 某个Agent频繁输出错误格式 | 模型与任务不匹配 | 换更强模型或降低复杂度，增加few-shot示例 |
| 流程卡住不动 | 调度器队列积压 | 查看worker队列长度，增加并行worker |
| 模型调用成本飙升 | 失败重试过多 | 设置重试次数上限，增加缓存与降级策略 |
| 人工审批列表长时间为空 | 规则把该转人工的单子自动放行 | 检查policy_check阈值和风险等级判定 |
| 工作台界面看不到任务进度 | 调度器日志未回写 | 检查异步消息队列和数据库连接 |
这张表是我上线后维护最常用的东西。排查问题不要靠猜，先看日志，再看队列，最后看模型响应，基本都能定位。
5. 生产落地建议：想清楚这三件事再上
5.1 给每个 Agent 写一份“岗位说明书”，并接受它的不完美
很多项目失败，不是技术不行，而是业务方对 AI 团队有超出实际的期待。Agent 再强也只是一个岗位，不是一个万能的人。想让 Agent 稳定产出，必须给它非常清楚的岗位说明书：什么该做，什么不该做，什么情况下要停下来问人。业务方的预期也要对齐，模型的判断会有概率性错误，这不是上线后修补就能消除的，而是要靠规则和人工节点来兜底。
我实际项目里的做法是，每个 Agent 对应一页纸的说明书，领导和业务代表都能看懂。如果业务方没法用一句话说清某个岗位的职责边界，这个 Agent 就不要急着创建，先帮业务方把流程理清楚。
5.2 宁可流程慢一点，不可绕过质量校验节点
有人为了让流程“看起来很 AI”，把质检节点去掉，让 Agent 直接执行完就结束。短期看效率确实高，长期看是灾难。AI 执行完以后，没有复核环节，错误结果就会直接进入业务系统，等到用户投诉再去追责，代价远大于那几秒钟的校验时间。
MyCoWork 里质检节点不是摆设。每个高风险流程的最后一个节点，我都会放一个 review Agent，或者直接接人工抽检。即使是自动放行的小额单子，也会保留完整的操作日志，方便事后审计。宁可让一条单子多走两三秒，也不要让一个错误结论直接成为业务事实。
5.3 试点从最平凡、最高频的业务流程开始
如果你正准备把 MyCoWork 引入团队，我给的建议从来不是挑一个“最有技术含量”的流程来试点，而是挑一个“最高频、最琐碎、最费人力”的流程。因为这类流程规则清晰，历史数据充足，业务方痛点明显，成功标准也好判断。
我自己第一个成功落地的场景是“售后工单自动分类与初步处理建议”。这个流程一点不炫酷，但每天几百张工单，每张都靠人肉看，团队早就烦了。MyCoWork 上线后，工单自动分类准确率到了可接受水平，业务方第一次觉得 AI 是真的在帮他们干活，而不是做一个“AI 大屏”给领导参观。从那以后，再往其他流程扩展，阻力就小了很多。
最后分享一个小经验：项目开源了大半年，很多人拿到手以后第一句话是“怎么没有可视化编排界面”，第二句话是“能不能直接导入我行业的模板”。这两点确实很重要，但比它们更重要的，是先把一个最小的、真实的业务流程跑通。把一条流程从配置到上线完整走一遍，你对多智能体的理解、对行业工作台的取舍，会比看十篇文档都扎实。MyCoWork 的默认资产可以当起点，但真正适合你业务的 AI 团队，一定是从你所在行业最普通的那条流程里长出来的。
