企业官网建设流程全解析

如果你最近在折腾 AI Agent 相关的项目，大概率绕不开一个词：多智能体协作。我个人的体感很直接——单 Agent 能做的事情，边界其实非常明显：上下文窗口有上限，工具链一多就乱，任务稍微复杂一点就开始“一本正经地胡说八道”。这也正是我为什么在调研了一圈之后，最终把 Multica 作为主力开源多智能体团协作平台来用。Multica 解决的核心问题，是让你可以像组建一支工程团队那样，把多个大模型智能体组织在一起：有人负责调研、有人负责推理、有人负责执行、有人负责审查，彼此通过结构化消息协作，把原来一个人干不动的复杂任务拆解成一条可追踪、可控制的协作流水线。

这篇内容面向的是正在做 AI Agent 应用的开发者、研究多智能体系统（MAS）的团队，以及正在评估要不要上多智能体架构的技术负责人。我会从平台定位、架构原理、部署步骤、实际配置样例，到生产环境里的坑和调优策略，全部拆开讲一遍。内容基于我实际部署和使用的经验整理，凡是涉及通用实践的部分，我会标注清楚哪些是平台自带能力，哪些是我自己补充的组合方案，方便你对照自己的环境做取舍。

1. 多智能体协作的应用背景与Multica的定位

先别急着看配置，想清楚“为什么需要多智能体”比“怎么配置多智能体”更重要。如果你只有一个简单的问答机器人需求，上多智能体反而会引入不必要的复杂度和成本。我见过不少团队把单 Agent 能干的事硬生生拆成五个 Agent，最后卡在消息协调上，性能还不如原来。

1.1 为什么单Agent不够用，多智能体才值得上？

单 Agent 的瓶颈我总结下来主要有三个，这也是所有想往多智能体方向走的团队迟早会遇到的问题。

第一个是上下文窗口限制。大模型的上下文长度虽然一直在涨，但实际使用中不可能把长文档、多轮对话记录、工具返回结果全部塞进去，成本和响应延迟都扛不住。单 Agent 一旦任务链条变长，早期的关键信息会被“挤出”注意力范围，结果就是做着做着就忘了最初的约束。

第二个是工具链耦合。让一个 Agent 既会联网搜索、又会写代码、又会操作数据库、又要润色文案，听起来全能，实际上每次调用都要切换工具上下文，出错率会直线上升。我见过最典型的案例是一个“全能”Agent 在同一个任务里连续犯三次低级错误，原因就是工具返回结果把系统提示词都给污染了。

第三个是单点失败。单 Agent 没有复核机制，一旦某一步推理跑偏，整个任务的输出全部作废，而且很难定位是哪一步出了问题。开发的时候还可以人工盯着，到了生产环境、异步跑批量任务的时候，这种不可控会让运维很痛苦。

多智能体协作的价值，其实就是用“分工”来解决这三点。把任务拆成多个专业角色，每个 Agent 负责一个窄范围的工作，上下文自然变小、工具链自然变短；再引入一个独立的 Agents 互相审查，推理偏差在流程内部就能被拦截。用一个比喻来说：单 Agent 是一个人加班写全栈项目，多智能体是一支有产品、开发、测试的工程小队，前者灵感好，后者交付稳。

1.2 Multica 是什么？它解决了什么问题

Multica 是一个开源的多智能体团队协作平台，核心目标是提供一套部署简单、可控性强的运行时环境，让开发者能把多个 LLM Agent 编排成一个可运转的协作系统。简单来说，它做了四件事：Agent 注册与生命周期管理、任务编排与调度、Agent 之间的消息路由、以及工具/插件的统一接入。

和轻量级的单 Agent 框架不同，Multica 从设计上就更强调“团队形态”。它默认支持把不同 Agent 配置成不同角色，角色之间通过结构化消息通信，而不是把一大段对话全部塞给同一个模型。这意味着你可以为每个 Agent 指定不同的模型——便宜的模型做检索分类，强大的模型做深度推理，这在实际使用中能省下非常可观的成本。

选择开源方案的原因也很实在。第一是数据可控，所有调度记录、消息日志、Agent 提示词都可以放在自己的服务器上，不会因为第三方平台策略调整被迫迁移；第二是可扩展性，团队自己接内部工具、写自定义 Agent 的时候，开源代码可以改底层逻辑，而不只是做配置层面的拼接；第三是社区生态，多智能体领域发展太快，闭源平台的功能迭代跟不上研究进展，开源项目至少能让你看到下一步演进方向。

另外一个值得提到的点是许可证。Multica 的整体授权比较友好，商用和二次开发都没有明显的束缚，这点对于企业内部落地很关键，尤其是想基于它做行业垂直方案的时候，不会第一天就踩许可证的坑。

2. 平台架构与技术原理拆解

配置之前先讲架构，因为多智能体系统调试难度比单 Agent 高一个量级，你不理解底层机制，出了问题根本不知道从哪查起。Multica 的整体架构我从运行角度看，可以划分为三个平面：控制平面、智能体平面和工具平面。

2.1 整体架构：三个平面各司其职

控制平面是整个平台的大脑，包含编排器（Orchestrator）、调度器（Scheduler）和会话状态管理器。编排器负责解释你定义的任务流——哪个 Agent 先执行、哪个 Agent 后执行、分支条件怎么判断；调度器负责任务队列和并发控制，决定多少个 Agent 实例可以同时运行；会话状态管理器维护整个任务链的共享上下文，保证 Agent A 的输出能正确传给 Agent B。

智能体平面是真正跑模型推理的地方。每个 Agent 实例由三部分组成：系统提示词、模型配置、工具列表。系统提示词定义了角色的行为边界和输出格式要求；模型配置决定调用哪个 LLM 以及温度、最大 token 等参数；工具列表是这个 Agent 可以调用的外部能力清单。这些组合在一起，就是一个有明确“岗位职责”的虚拟成员。

工具平面则是外部能力的统一入口。不管是搜索 API、代码执行环境、内部数据库、还是第三方 Webhook，都通过统一的工具注册中心挂载到平台上。Agent 需要调用工具时，不是直接拼 HTTP 请求，而是向工具平面发一个调用意图，由工具平面做参数校验、鉴权、限流和结果返回。这样做的最大好处是安全边界清晰——一个 Agent 就算被提示词注入恶意指令，它也只能调用白名单里的工具，炸不出外层。

三个平面之间的协作方式，用快递中转站来理解最直观：控制平面是中转站的分拣员，智能体平面是各条运输线的司机，工具平面是干活的仓库工人。司机不需要亲自去仓库找货，只需告诉分拣员“我要送什么东西”，分拣员按规则分配给合适的工人，再让下一个司机接手。

2.2 编排模式：链式、路由与图式调度

多智能体的“多”不是目的，“协作”才是。Multica 支持的编排模式，我实际用下来可以分成三类，分别对应不同复杂度的任务形态。

链式编排是最基础的，Agent A 的输出直接作为 Agent B 的输入，依次顺序执行。典型场景是“先检索资料，再写总结，最后翻译成英文”。这种模式实现简单、链路清晰，在排障的时候也最容易定位——卡在哪个环节，看哪个 Agent 的日志就行。

路由编排适合“任务需要分流”的场景。比如用户发来一个问题，系统先由一个分类 Agent 判断这是技术类、财务类还是法律类问题，然后路由到对应的专家 Agent。这里分类 Agent 扮演的就是一个智能路由器，Multica 里可以通过在流程配置里定义条件分支来做，条件命中哪个分支就走哪个分支。

图式编排是最复杂的形态，任务可以把多个 Agent 并行展开，最后汇聚合并。以写一份市场分析报告为例：调研 Agent 和数据分析 Agent 可以同时启动，两者都完成后再交给撰稿 Agent 整合。图式编排能最大限度发挥多 Agent 并行优势，但难点在于必须处理并行分支的同步问题——一个分支失败了，到底是整体重跑还是只重跑失败分支？Multica 的默认规则是只重跑失败分支，然后重新做汇聚，这个设计在实际使用中非常合理，省了不少成本。

从我个人经验来看，编排模式的选择原则很简单：能用链式绝不用路由，能用路由绝不上图。复杂度越高，调试成本越高，系统行为越难预测。先跑通最小闭环，再逐步升级编排模式。

2.3 消息通信与上下文共享机制

多 Agent 协作的本质是消息传递。Multica 里 Agent 之间不直接对话，而是往消息总线（Message Bus）上发送结构化消息。每个消息包含三个部分：消息头（发送者、接收者、消息类型、消息 ID）、载荷（实际内容）、元数据（时间戳、追踪 ID、重试次数）。这个设计的价值在于，整个协作过程可以被完整记录和回放，而不是像两个大模型在聊天对话框里互发文字那样无法追踪。

我特别想强调一点：多智能体系统里最容易被忽视的是共享上下文管理。Agent A 调研出 50 条资料，Agent B 做分析时不可能读全部原始内容。Multica 的做法是支持共享记忆区，通常挂在一个向量数据库上。Agent A 产出结果后，先把重要信息提炼成摘要写入共享记忆，Agent B 通过检索拿高相关度的片段。这个机制模拟了真实团队里“白板讨论”的效果——信息是沉淀下来的，而不是靠口头转述。

消息路由方面，Multica 支持基于主题（Topic）的订阅模式和点对点的定向分发。主题订阅适合广播类消息，比如“全员注意任务目标变了”；定向分发适合流水线式的任务交接。生产环境我强烈建议所有消息都带上下文 ID，否则排查问题的时候，几十个 Agent 的日志混在一起根本没法看。

3. 安装部署与初始配置实操

这一节的内容全部基于我自己实际在服务器上部署 Multica 的经验。我用的环境是一台 4 核 8G 的云服务器，操作系统是 Ubuntu 22.04，生产环境建议至少 8 核 16G，尤其是跑复杂图式编排的时候，内存不够会直接 OOM。

3.1 环境要求与依赖准备

Multica 的部署方式主打 Docker Compose，它对宿主机的要求不算苛刻，但有几个依赖是必须提前准备齐的。

第一是 Docker 和 Docker Compose 插件，版本不要太旧，我遇到过 Docker 版本过老导致 Compose 语法解析失败的问题。第二是需要一个外部 Redis 实例做消息总线和任务队列，如果你只是本地验证，Compose 文件里直接拉一个 Redis 容器就行；生产环境建议用独立的 Redis，方便单独做持久化和监控。第三是向量数据库，用于共享记忆存储，默认支持主流开源向量库，也可以对接云厂商托管版本。

磁盘方面，镜像占用加上日志增长，建议预留至少 20G 空间。多 Agent 系统的日志增长非常快，每个任务每一步调用都会写日志，我跑一周之后发现日志占了大几个 G，后面会给排障经验里加一条日志轮转的建议。

网络方面需要注意，如果服务器在国内，拉取镜像和调用海外模型 API 的延时都不一样，建议提前配置好镜像加速，并且保证模型 API 的连通性符合你的使用预期。

3.2 基于Docker Compose的部署步骤

部署流程我用的是标准套路，不复杂，但每一步都有值得注意的细节。

第一步，先把项目代码克隆到服务器上，拉取方式用 git clone 项目仓库地址到本地即可。这里要注意：不要直接 clone 到 root 用户的家目录，很容易遇到目录权限问题，建议 clone 到 /opt 或 /srv 下面，并给当前用户授权读写权限。

第二步，检查 docker-compose.yml 文件。Multica 的 Compose 文件会定义控制面服务、Worker 服务、Redis、向量数据库和可选的消息队列。默认配置里端口映射、依赖关系都已经写好了，但有几个参数要根据自己的环境改：一是控制面板映射到宿主机的端口，默认是 8080，如果你想换成别的端口直接改映射关系；二是时区配置，改成你所在时区，否则日志时间看着乱。

第三步，配置环境变量。主要是模型 API 的密钥，建议不要写在 Compose 文件里，而是放到 .env 文件里，并且把 .env 加入 .gitignore。我见过有人把密钥直接提交到 Git 仓库，这是严重的操作失误，尤其在开源项目上。密钥泄露不只是费用问题，还可能被恶意利用去跑违规内容。

第四步，启动服务。执行 docker compose up -d 之后，先观察容器状态，用 docker compose ps 查看是否都在 running。首次启动需要拉取多个镜像，耗时取决于网络，正常情况下五到十分钟内能完成。

第五步，检查健康状态。Multica 控制面板暴露了一个健康检查接口，用 curl 访问 /healthz 路径，返回正常 JSON 就说明控制面起来了。首次启动后建议耐心等待日志中出现“所有 Worker 已注册”之类的信息，这表示智能体平面已经就绪。

3.3 首次登录与全局配置检查

部署完毕后，浏览器访问服务器的 8080 端口就能打开控制面板。默认账号和密码会在初始化日志里生成，首次登录后强制要求修改密码，这步不要跳过。控制面板首页有四个核心区域：Agent 列表、任务流程列表、运行记录、系统监控。首次登录最该先看的不是 Agent 列表，而是设置页面里的全局配置。

全局配置主要检查四项：模型提供方配置是否正确、默认模型参数是否合理、共享记忆的向量库连接是否成功、工具注册中心里有没有可用的内置工具。尤其是模型配置，我建议在控制面板里直接跑一次“连通性测试”，确认平台能正常调用模型 API，再开始创建 Agent。别小看这一步，我见过有人配了半天 Agent，最后发现是 API 密钥少了前缀，所有调用全部 401，排查了整整一晚上。

第一次登录还有一个容易忽略的地方：Worker 节点默认可能没有开启 Agent 执行权限。Multica 的安全设计里，Worker 不会直接执行任意 Agent，需要你在配置里勾选允许执行的 Agent 类型。这个设计安全是安全，但新手往往会忘记勾选，导致任务提交后排不进队列。如果你发现任务一直处于 pending 状态，优先检查这一步。

4. 构建一个最小可用的多Agent协作流程

看完部署，下一步就是跑一个真实任务。我选了一个非常典型的场景来讲：给定一个技术方向，自动生成一份行业调研报告。这个任务同时覆盖了检索、分析、写作和审查四个环节，非常适合用来理解多 Agent 协作的工作方式。

4.1 场景设计：用四个角色形成一个最小团队

这个场景里，我把团队拆成了四个角色：

• 调研员 Agent：负责对接搜索工具，采集指定方向的技术资料、市场动态，产出原始信息集。
• 分析师 Agent：读取调研员的结果，提炼关键趋势、优劣势、数据指标，产出结构化分析摘要。
• 撰稿人 Agent：基于分析摘要撰写一篇有逻辑的调研报告，输出 Markdown 格式文档。
• 质检员 Agent：负责核查报告，检查是否有遗漏关键点、是否有明显的错误结论，不合格就打回给撰稿人修改，合格才放行。

为什么这样拆？关键在于每个角色的上下文边界都很干净。调研员不需要知道报告怎么写，它只需要输出结构化信息集；撰稿人不直接面对大量检索结果，它拿到的是一份提炼好的摘要，写起来准确率高得多；质检员作为最后一道防线，能把错误拦截在交付之前。四个角色各自用不同的系统提示词约束行为，协作起来效率比单 Agent 硬扛要高很多。

4.2 定义Agent角色与编写编排配置

Multica 的 Agent 定义我习惯用 YAML 来维护，一份 agents.yaml 文件把所有角色写清楚，提交平台后自动注册。下面这个是我实际在用的配置范式：

agents: - name: researcher role: "行业调研员" system_prompt: | 你是一名专业的行业调研员。你的任务是使用搜索工具收集 指定行业的最新资料，输出结构化信息集，包含：技术关键点、 主要参与者、市场数据、时间线。只输出事实，不做结论推断。 model: "gpt-4o-mini" max_iterations: 8 tools: - web_search - web_extract - save_memory - name: analyst role: "趋势分析师" system_prompt: | 你是一名行业趋势分析师。输入是调研员收集的结构化信息集， 你的任务是提炼核心趋势、风险与机会，输出一份结构化分析摘要。 必须引用来源编号，不添加虚构信息。 model: "gpt-4o" max_iterations: 6 tools: - read_memory - save_memory - name: writer role: "报告撰稿人" system_prompt: | 你是一名资深行业报告撰稿人。输入是分析师的摘要，你的任务是把 摘要扩写成一份结构清晰的 Markdown 调研报告。报告包含：摘要、 行业现状、核心趋势、风险与挑战、结论建议。语言要求简洁专业。 model: "claude-3.5-sonnet" max_iterations: 10 tools: - read_memory - file_writer - name: reviewer role: "质检员" system_prompt: | 你是一名严格的内容质检员。检查报告是否覆盖了分析摘要中的所有 关键点，是否出现数据矛盾或过度演绎。通过标准：结构完整、来源 清晰、结论与数据一致。不通过则返回修改意见，最多审查2轮。 model: "gpt-4o" max_iterations: 5 tools: - read_memory - review_report

这段配置里有几个细节值得展开讲讲。

system_prompt 是 Agent 的灵魂，必须写得足够具体。我这里给每个角色都写明了输入是什么、输出是什么、禁止做什么，这样模型才不至于跑偏。“只输出事实，不做结论推断”和“必须引用来源编号”这两条是我在真实项目中验证过的高价值约束，能显著减少信息幻觉。

model 字段的选择逻辑是成本与能力的平衡。调研员用 mini 模型就够，因为它的任务是检索和整理，不需要深度推理；分析师和质检员用 gpt-4o，因为要判断趋势和检查矛盾；撰稿人用 claude-3.5-sonnet，实测它长文本组织能力强，写报告的结构感明显更好。这就是多 Agent 带来的另一个好处：不是所有环节都被迫用最贵的模型。

max_iterations 必须设置。这本质上是给每个 Agent 的“工作量上限”，防止模型陷入死循环。我见过最离谱的一次，一个 Agent 因为工具返回结果格式异常，反复重试了 20 多次才被管理员手动杀掉，白烧了不少 token。设置上限之后，超出就标记失败，走失败处理逻辑。

Agent 定义好之后，还需要一份流程编排文件。这个文件描述的是四个角色怎么配合，我用下面这种简化结构示意：

flow: name: "行业调研报告流程" nodes: - id: 1 agent: researcher action: run - id: 2 agent: analyst action: run inputs_from: [1] - id: 3 agent: writer action: run inputs_from: [2] - id: 4 agent: reviewer action: run inputs_from: [3] retry_target: 3 max_retries: 2 final_output: 4.output

这段配置的语义很直白：调研员跑完，结果给分析师；分析师出摘要，传给撰稿人；撰稿人提交报告，质检员检查。如果质检不通过，流程会回到撰稿人节点重写，最多重写两次。这个“回退重试”机制是我认为多 Agent 平台最值钱的能力之一，它让质量保证真正成为流程中的一个环节，而不只是靠运气。

4.3 运行流程与结果观察

配置提交后，在控制面板点击运行任务，输出一个调研目标“低空经济领域的技术趋势”。整个流程跑完大概用了 4 分钟，具体耗时分布是：调研员阶段约 90 秒，分析阶段约 40 秒，撰稿阶段约 80 秒，审查阶段约 30 秒。最终产出的报告质量，比我之前用单 Agent 直接写高了不止一个档次——写得快不一定，但结构化程度和引用准确率提升非常明显。

运行过程中值得观察的细节有三个。一是消息流转记录，可以看到每一步是谁传给谁的、消息大小是多少，这有助于判断链路中是否有冗余；二是工具调用轨迹，能查到每一步调了哪个工具、参数是什么、返回了什么，这在出问题时是核心排查依据；三是节点耗时，如果某个 Agent 耗时异常长，通常说明输入太长或者工具调用遇到了阻塞。

如果你是通过 API 接入而不是人工在面板操作，Multica 也提供了完整的任务提交接口。你只需要向指定接口 POST 一个 JSON，里面写明 flow 名称和初始输入即可；返回的任务 ID 可以用来轮询任务状态。这块我自己在实际开发里用得多，算是一个很实用的集成方式。

任务跑完，我建议先人工核对一遍输出，尤其是质检员通过的报告，也要抽检。多 Agent 系统能降低错误率，但不能完全消灭错误，尤其在信息检索类任务里，检索源本身如果有偏见，Agent 很难察觉。质检员能检查逻辑一致性，但很难查“来源是否权威”这种需要经验判断的问题。

5. 生产环境避坑与调优实战

多 Agent 系统，配置起来快，调稳却需要时间。这一节我会把我踩过的坑、查到深夜才解决的问题，都按“现象-原因-方案”的形式写出来，都是我真实遇到过的。

5.1 消息风暴与任务卡死问题

现象：任务提交后一直处于运行状态，看日志发现两个 Agent 在反复交换消息，像两个人在互相踢皮球，谁都不往前推进。

原因：最常见的是系统提示词里没有定义“退出条件”。比如一个审查 Agent 觉得内容不过关，打回给撰稿 Agent；撰稿 Agent 修改后，审查 Agent 还是不满意，又打回；如此循环。如果没有最大迭代限制，这个循环很难自己停下来。

解决方案：第一，在每个 Agent 的 max_iterations 里设置合理上限，这是硬保障；第二，在审查类 Agent 的提示词里写清楚“连续两轮仍不合格时，按通过处理并附上风险说明”，给循环一个程序化的出口；第三，为流程设置整体超时时间，超过就直接标记失败，避免任务永远挂在那。实测下来，这三条组合能拦掉 90% 以上的死循环问题。

还有一个容易忽略的点：消息里不要塞太多历史记录。有些 Agent 为了保留上下文，会把前几轮的消息全部附加在下一轮请求里，导致上下文越来越长、调用越来越慢、费用越来越高。我建议所有 Agent 都只消费“上一节点的输出摘要”，而不是完整的原始记录。

5.2 Token成本失控与模型路由策略

现象：月度账单比预期高出 3 倍，仔细排查发现大部分消耗并不在复杂推理上，而是浪费在简单的格式化、标签提取等低价值环节。

原因：我一开始把所有 Agent 都配成了同一个高规格模型，导致检索结果整理这类机械工作也在用最贵的模型跑。多智能体系统里，Agent 数量多、调用频繁，成本偏差会被放大得非常严重。

解决方案：建立模型分级路由。粗活、累活、机械活用便宜的小模型，比如内容分类、抽取、格式化；需要深度分析、推理、生成核心内容的环节才用强模型。Multica 支持按 Agent 单独配置模型，这个特性就是用来做成本精细化的。另外，每轮 Agent 响应设一个 max_tokens 上限，防止某个模型跑飞输出几万 token 的废话。

成本排查我习惯用表格来追踪，下面是我常用的模板：

这张表跑一周就能看出哪个环节支出不合理，再针对性做优化。我强烈建议所有上多 Agent 系统的团队都建这么一张追踪表，否则成本失控的时候你根本无从下手。

5.3 工具权限与数据安全边界

现象：某个 Agent 在调用内部数据库查询时，把包含敏感字段的数据带到了后续所有 Agent 的上下文里，虽然没有泄露到外部，但日志里到处都是敏感信息的明文。

原因：Agent 的能力边界没有做数据分级。调研员和分析师本不需要访问内部数据库，但因为我给它挂载了过宽的工具权限，它就能调用到远超需求的数据。

解决方案：遵循最小权限原则。每个 Agent 只能挂载它完成任务所必需的工具，宁可多注册几个专用工具，也不要给一个万能工具。对于涉及敏感数据的外部工具，必须在工具层做字段过滤，比如说查询接口只返回指定字段，其他字段一律不落日志。密钥管理上，所有工具调用的凭证都通过环境变量注入，不写进 Agent 的系统提示词。

另外一个安全细节是日志脱敏。多 Agent 系统的日志会记录消息内容，如果消息里包含敏感业务信息，日志文件本身就是风险点。我现在的做法是在工具调用层做一次脱敏处理，把身份证号、手机号、密钥这类字段替换成掩码，再进入日志系统。

5.4 什么场景适合上多Agent？我的建议

最后这点是我最想分享的：不是所有场景都需要多智能体，硬上只会增加运维负担和调用成本。我自己的选择标准是，任务满足“复杂拆解、多能力要求、可验证、需要审计”这四个条件之一时，才值得用多 Agent 架构。

• 复杂拆解：任务内部存在明显的子步骤，且子步骤之间是上下游关系。
• 多能力要求：任务需要同时用到检索、推理、代码执行、写作等两三种以上能力。
• 可验证：任务有相对明确的质量标准，比如内容覆盖度、数据一致性，否则协作链条没有收敛目标。
• 需要审计：每次执行的中间过程需要留痕，便于事后追踪责任。

如果只满足一两条，用单 Agent 配合工具链可能就够了，成本更低，维护更省心。从单 Agent 往多 Agent 迁移时，我也建议渐进式推进：先让两个 Agent 协作跑通一个业务流程，稳定之后再扩展成团队，一次加太多角色很容易让系统行为失控。

最后再分享一个我真实踩过的坑：最初我把所有 Agent 的系统提示词都写得很模糊，觉得模型厉害，自己能领会。结果跑出来的协作质量很不稳定，有时候好得惊人，有时候差得离谱。后来我花了整整一天，把每个角色的提示词改成了“输入是什么、输出是什么、边界是什么”的三段式结构，质量才稳定下来。系统提示词不是摆设，它本质上就是你团队的“岗位说明书”，岗位职责写得越清楚，协作效率就越高。