企业官网建设流程全解析

我最近在做一个多人多AI协同的试验台：四个协作者通过一个统一的代理网关，同时调度三个本地开源模型和两个云端API模型，一起完成产品需求拆解、技术方案评审和排期预估这类偏文档性的协作任务。第一版跑通之后，我最深的感受是：最大的问题根本不是单个模型聪不聪明，而是"谁在什么时候应该听谁的""同一个上下文该以谁的版本为准""两个AI给出矛盾结论时如何处理"——这些问题在单用户单AI时代完全不存在，一旦人数和模型数量同时上去，就会集中爆发。

这篇文章想把我在"AI代理代为交互"这个方向上的研究和工程实践拆开讲清楚：为什么需要代理这一层，多人多AI协同的系统架构到底该怎么分、每一层承担什么职责，以及我在落地中踩过的坑和积累的优化经验。内容适合正在做多Agent项目、想把单AI助手升级成团队级协同平台、或者纯粹对多智能体系统架构感兴趣的朋友参考。我们会先从"为什么非代理不可"讲起，再给出一套可落地的分层架构，后面几章分别讨论冲突消解、记忆管理、消息协议、性能瓶颈和安全审计，这些都是我把系统真正跑起来之后才意识到的高优先级问题。

1. 为什么"代理代为交互"不是锦上添花，而是多人多AI协同的前提条件

1.1 人类直连AI的三个固有瓶颈

我们先把"多人多AI协同"拆开看：多人，意味着多个用户同时在场，各自有诉求和上下文；多AI，意味着多个模型并行工作，能力边界、知识截止日期、风格甚至脾气都不一样。如果让每个人直接去连每个AI，很快就会撞上三个绕不开的墙。

第一堵墙是注意力带宽。一个用户在同一时间只能认真盯住一个对话流。设想一个六人团队，每人同时使用两个AI，整个系统里同时存在十二条正在产出的对话流。谁来看全局？谁把A用户让AI改完的方案同步给B用户正在对话的那个AI？人工转发只会让人变成系统的搬运工，这和用AI的初衷完全相反。

第二堵墙是上下文隔离。默认情况下，每个AI会话都是独立的，用户必须手动把上一个AI的结论复制粘贴给下一个AI。单次还能忍受，一旦形成常态，系统就没有"公共信息面"，多个AI各说各话，信息在人工复制过程中还会失真、遗漏版本。

第三堵墙是权限粒度。在真实协作里，不同成员对信息的可见范围和操作权限是不同的。直连模式下，用户只要拿到某个AI的会话入口，基本就能看到这个会话里的全部内容，根本没办法做到"这个项目的预算明细只有项目经理和财务能看，其他模型输出默认脱敏"。

这三个瓶颈的本质是：多人多AI协同是一个有状态、有约束、有多方博弈的系统问题，而AI模型本身是无状态的、单次请求响应的。中间必须有一个东西来补上状态、约束和博弈协调，这就是"代理"层存在的原因。

1.2 代理层的本质：一个数字项目经理

所谓"AI代理代为交互"，我的理解是：把传统的"人—AI"两点直连，改造成"人—代理—AI"三点结构。代理不只是一个API转发网关，它同时承担四个角色。

• 路由者：根据用户意图、模型能力标签、负载情况，决定一条请求应该交给哪个AI，或者拆成多个子任务分发给多个AI。
• 仲裁者：当多个AI给出互相矛盾的结论、多个用户提出互相冲突的需求时，代理按预设策略进行裁决，或者把冲突以可读的方式呈现给人类。
• 记忆管理员：维护共享工作记忆、AI私有记忆、用户私有记忆三个空间，负责读写权限和上下文压缩。
• 审计者：记录从用户原始指令、代理改写后的指令、模型原始输出到最终执行动作的全链路信息，保证出了问题可以追溯。

打个比方：一个公司里不可能每个员工都直接找其他所有部门的人开会，而是通过项目经理、项目群这类角色来做信息汇总、冲突协调和决议记录。代理就是那个"数字项目经理"。它不需要比会议室里的任何一个人更聪明，但必须比任何人都更清楚"当前谁在做什么、谁需要知道什么、什么决定已经做了"。

这个定位非常重要，因为它决定了我们对代理层的能力要求不是"更强的语言理解"，而是"可靠的流程控制、可解释的决策逻辑、可回滚的操作记录"。

2. 分层架构的整体设计：接入、调度、协同、执行与审计各司其职

2.1 五层架构的职责边界

在试验台里，我把系统设计成五个逻辑层，严格规定每一层做什么、不做什么。边界清晰是我踩了两次坑之后才真正守住的规矩：一旦某层越界，排查问题的难度会指数上升。

• 接入层（Interaction Layer）：负责接收Web端、IM客户端、API调用等不同来源的请求，把各种输入统一定义成标准化的"意图信封"。这一层不判断业务对错，只做格式统一、身份识别和基础频率控制。
• 调度层（Orchestration Layer）：这是代理的大脑。它把意图信封翻译成可执行的任务，决定请求该交给哪个AI、是否需要拆解成子任务、多个子任务之间是否有依赖关系。同时负责把已经完成的任务结果合并成一条完整响应。
• 协同层（Collaboration Layer）：核心是共享工作空间，包括共享黑板（Shared Blackboard）、共识仲裁模块、上下文管理中心。所有AI产出的可共享信息都写入黑板，所有跨AI的信息查询都通过这一层。仲裁模块在这里处理意图冲突和答案分歧。
• 执行层（Model Gateway & Tools）：管理模型实例和外部工具。模型网关统一封装本地模型和云端API，提供并发池化、超时控制、failover。工具调用（读文件、执行脚本、发通知）也在这层做权限拦截。
• 审计层（Audit & Boundary Layer）：贯穿前四层，负责权限校验、敏感信息隔离、完整链路日志。所有层的通信都过审计层的旁路日志通道，方便以后做操作回放。

这五层的调用链是单向依赖：接入层只依赖调度层，调度层只依赖协同层和执行层，协同层只依赖执行层，审计层作为横切层旁观一切但不阻塞主链路（除权限拦截外）。

2.2 为什么协同逻辑必须独立成层，而不是塞进模型提示词

我在第一版设计里犯过一个典型错误：试图靠提示词让单个AI去协调其他AI。具体做法是，给一个"主控模型"写一段复杂的指令，让它自己决定何时调用其他模型。实践证明这个方案非常不稳定，原因有三个。

第一，模型对状态的管理能力极其有限。上下文一长，模型就会"中间遗忘"，很难保证它还记得哪个子任务派给了哪个AI、结果回来了没有。协同调度是一个强状态问题，我用Redis记录任务状态都比靠模型记忆可靠得多。

第二，提示词不可检验。你没有办法用单测去验证"主控模型是否严格遵守了冲突仲裁规则"，因为它是一个概率系统。而把仲裁逻辑写进协同层的代码里，每条规则都对应一个可测试的分支，出了问题可以准确复现。

第三，成本太高。每次协调都让一个强模型读全量上下文做决策，token开销成倍上涨，而结果并不比一个几百行的路由规则更可靠。

所以我的原则是：能用代码表达的规则不用提示词，模型只负责那些真正需要语义理解的部分（意图识别、结果生成、语义相似度判断）。

2.3 层与层之间的数据流向

一个典型请求的完整路径是这样的：用户A发出一条消息，接入层把它打包成意图信封，调度层识别出这是一个需要"技术方案评审"的任务，于是把任务拆成三个子任务：方案完整性检查交给模型1，风险点分析交给模型2，成本估算交给模型3。三个模型的结果并行写回协同层，协同层把结果聚合后交给仲裁模块——这里发现模型2和模型3的成本估算差了一倍，于是触发答案冲突仲裁，仲裁结果和差异说明一起返回给用户A。整个过程中，审计层记录了每一步的输入输出和参与方。

这个路径看起来简单，但每一个环节都有值得深挖的工程细节，下面几章逐一展开。

3. 冲突消解机制：多人意图冲突与多AI答案分歧怎么仲裁

3.1 先给冲突分个类

协同系统里，冲突不是偶发异常，而是常态。我把实测中遇到的冲突归纳成三类，每一类的处理策略完全不同。

• 意图冲突：发生在用户之间。用户A说"预算压到5万"，用户B说"按8万报"，代理无法同时满足。
• 答案冲突：发生在AI之间。两个模型对同一个事实问题给出不同回答，或者对同一个开放性问题的建议方向完全相反。
• 资源冲突：发生在任务之间。两个AI同时要写同一个文件、同时占用同一块GPU、同时调用同一个外部接口，处理不好就会互相覆盖或死锁。

3.2 三类冲突的仲裁策略

意图冲突的核心原则是"提前定规则，而不是出事再逼模型思考"。我在协同层的配置里维护了一张优先级表，比如"财务角色的预算指令优先于产品角色的预算建议""后发出的指令默认覆盖先前的临时指令，但不能覆盖已标记为正式决议的指令"。规则冲突能力有限，但大部分情况能自动处理，真正进入人工兜底的场景反而很少。

答案冲突我会多说几句，因为这是多AI系统特有的麻烦。处理流程是这样的：从多个AI的答案里分别抽取结论和依据，用文本相似度对结论做聚类；如果所有AI结论基本一致，就按最高可信度选择主答案，其他作为补充；如果聚成两个以上明显不同的阵营，就把每个阵营的代表性回答连同其引用来源一起放进"差异报告"。关键点是：不要让代理偷偷选择一个答案然后藏起其他答案，人类需要看到分歧本身，而不是代理替他们拍板。

3.3 一个实测案例：预算数字之争

试验台里真实发生过一次典型案例。团队在做季度活动方案，模型2（本地开源模型，基于旧知识训练）估算线下场地加物料要9万，模型3（云端更大参数模型）根据团队上传的最新报价单算出5.5万。两个模型在共享黑板上都写了自己的结论，代理的答案冲突模块触发。

处理过程：仲裁模块先让两个模型各自补充"估算依据的引用路径"，模型2引用的报价数据是三个月前的，而黑板上有一份更晚的"供应商调价通知"，模型3引用了这份新通知。于是代理判断模型3的答案可信度更高，把模型2的结果标记为"基于过期数据"，主答案采用5.5万，同时保留了两份依据链接供人复核。

整个过程耗时不到10秒，关键是代理没有自己"觉得"哪边对，而是通过溯源引用把判断依据变成了可核查的事实链。这是我后来在所有多AI场景都坚持要求"答案必须能追溯到共享记忆中的具体资源"的原因。

4. 记忆与上下文管理：协同系统最容易翻车，也最值得加防护的地方

4.1 三空间记忆模型

多人多AI协同的记忆问题，比单用户场景复杂一个量级。我用三个逻辑上完全隔离的空间来管理：

• 共享工作记忆（Shared Blackboard）：所有参与者（人和AI）都可以写入的项目级信息，包括目标、决议、数据、进度。相当于团队公用的Confluence页面。
• AI私有记忆：每个AI代理自己的对话历史、偏好、推理过程。其他AI和用户默认不可见。
• 用户私有记忆：用户在系统里留下的个人偏好、个人草稿、权限以外的敏感信息。只有本人和获得授权的代理可以读取。

三个空间的权限严格递增：共享空间全员可读写（AI也分只读和可写两种角色），AI私有记忆只有所属代理和管理员可读，用户私有记忆默认全系统不可见。

4.2 读写权限与污染防范

我踩过最深的坑，就是共享记忆的"污染传播"。具体现象是：某个本地小模型在生成内容时产生了幻觉，把一段完全不存在的事情当成事实写进了共享黑板，结果后续三个AI都基于这段错误信息继续推导，整个项目讨论跑偏了将近一天才被用户发现。

从那以后，我给共享黑板的写入加了一道强制校验：任何AI要把结论写入共享记忆，必须先通过一道"事实校验闸门"。做法很简单，抽取结论里的关键断言（金额、日期、当事人、URL），在共享记忆里检索是否有证据支持；如果有明确的矛盾证据，就打回让AI修改；如果没有证据也没有反证，就标记为"未证实"而不是"事实"。这样即使幻觉内容进入黑板，后续AI读取时至少会看到灰色标记，不会盲目引用。

另外一个容易被忽视的点是：AI代理在共享记忆里的写入权限应该比人类更严格。人类写了错别字，其他人类看到会自动纠正；AI写了错误断言，其他AI往往直接引用。所以我在协同层给每个AI代理默认配置"只读"角色，需要主动申请"可写"角色，且所有AI写入都会在审计层留痕。

4.3 上下文压缩：分层摘要与按需回捞

协同系统的上下文长度是个大难题。共享黑板运行一个月后可能有几十万字，每个AI对话前不可能全量读入。我采用的方案是"分层摘要 + 按需回捞"。

具体来说，共享黑板的每个主题块维护三层结构：第一层是一个5句话以内的主题摘要，任何AI被问到这个主题时默认只读这一层；第二层是关键事实列表，格式是"事实+来源+更新时间"，适用于需要具体数据的场景；第三层是原文档案，包含所有原始讨论记录，只在需要溯源时按引用ID回捞。

这个设计的好处是token开销非常可控。调度层在给模型拼上下文时，会根据任务意图决定注入哪一层：泛泛了解主题就只注入摘要层，需要数字决策就注入事实层，需要复盘就回捞原文。实测中，同样的任务在优化前平均每个请求要漏读6000 token的上下文，优化后降到800到1500 token，而回答质量几乎没有下降——因为模型本来就处理不了那么长的历史，精简后反而更聚焦。

5. 消息协议、状态同步与失败降级的工程落地细节

5.1 消息信封设计与幂等

在接入层和调度层之间，所有消息都封装成统一的信封结构。我用的字段如下：

{ "msg_id": "msg_1a2b3c4d5e", "trace_id": "trace_20240607_001", "from": "user:alice", "to": ["agent:reviewer", "agent:estimator"], "type": "task.request", "intent": "review_tech_plan", "payload": { "doc_id": "doc_plan_v3", "focus": "risk_and_cost" }, "context_ref": { "memory_space": "shared_blackboard", "topic": "quarterly_campaign_budget" }, "created_at": 1717752345 }

每个字段都有自己的理由。msg_id是全局唯一消息ID，核心作用是幂等——代理在处理超时后重发消息时，接收方可以通过msg_id识别这是一条重复消息，直接返回上一次的处理结果，避免AI任务被重复执行、重复扣费、重复写板。trace_id是链路追踪ID，把所有相关消息串成一条完整的会话链条，排查问题时直接按trace_id拉全链路日志。

context_ref是这篇架构设计里我最坚持的字段。它的作用是指定这条请求在哪个共享记忆空间中工作、涉及哪个主题知识点。有了它，调度层在拼上下文时就能精准回捞对应层级的记忆内容，而不是盲目地把所有对话历史丢给模型。

5.2 为什么必须异步化：人机混合流程的节奏问题

多人多AI协同和单Agent最大的不同，是流程里混着大量等待人类的步骤。用户A请求AI生成方案，AI生成完了发现需要用户B做决定，于是任务挂起等B的响应。B可能三分钟就回复，也可能去开了一小时的会。

如果整个链路用同步调用，后面的所有任务都会被一个"等人类回复"的节点卡死。我的做法是全程异步消息总线：任务被提交到队列，运行状态机管理生命周期，任何任务到达"waiting_human"状态就释放所有计算资源，等用户响应事件到达后再由事件触发后续流程。调度层不会因为某个任务挂起而阻塞其他任务的派发。

这个设计初期会让人觉得"绕"，但跑起来后就真香。团队里任何人的响应速度都不再影响整个系统吞吐，AI在等待期间可以继续处理其他不依赖该决策的任务。

5.3 超时、重试与降级策略

多模型并行调度，最怕的就是某个模型API超时导致整个流程卡住。我沉淀了一套三级策略：超时重试、降级切换、任务分流。

• 第一级，超时重试：单次模型调用超过25秒，重试一次，重试时附带相同的msg_id保证幂等。
• 第二级，降级切换：如果重试仍失败，根据任务的类型选择备用模型。比如本地模型超时，切到云端API；云端小模型超时，切到云端大模型。降级后会在响应里标记"此结果来自降级路径"，让用户知道。
• 第三级，任务分流：如果一个子任务长时间无结果，调度层会把它拆成更小的子任务并行分发给多个AI，哪个先回就用哪个的结果，另一个作为冗余校验。

在任务状态机里，我用pending(排队中)、active(执行中)、waiting_human(等用户)、finished(完成)、failed(失败)、aborted(用户取消)六个状态。状态迁移全部记录到审计日志，任何一个任务卡住超过设定阈值，都会有监控告警推给我。

6. 实测性能瓶颈与优化手段：模型并发、Token开销与端到端延迟

6.1 瓶颈到底在哪里

我用的是三个本地开源模型（7B、13B、34B各一个）加上两个云端API模型。第一版全链路压测的结果很有意思：单个模型本身的推理延迟并不是主要瓶颈，真正的瓶颈出现在两个地方。

第一个是上下文拼接。每个任务进入执行层前，调度层都要去协同层拉取相关记忆，然后拼prompt。最初我采用"全量注入"策略，把共享黑板里所有相关主题块全部塞进去，结果光拼上下文就花掉4到6秒，token开销巨大，而且模型面对过长的上下文反而更容易答偏。

第二个是协同层的仲裁等待。当一个流程需要等两个AI都返回结果才能做答案聚合时，整个链路的延迟等于最慢的那个AI的延迟。如果你串行等待，端到端时间几乎是多个AI延迟的累加；即使并行，也要等最慢者。

实测数据大概是这样（本地单张消费级GPU，环境比较朴素）：

6.2 四个真正有效的优化手段

第一，轻量路由预筛。我用一个128M的fastText分类器做意图预筛，只判断任务类型和粗略的模型偏好，几毫秒出结果，完全不用大模型。只有意图模糊到超过阈值时才把语义判断交给大模型。这一下把路由开销降了一个数量级。

第二，上下文按需注入。就是上一章说的分层记忆回捞，数据收益最明显，token开销降低约七成。

第三，结果流式分发。之前我是等一个AI全部输出完，再等另一个，最后统一汇总。后来改成流式：每个AI的output token边生成边写入黑板草稿区，并在主看板推送给相关用户。用户看到第一个可用结果的时间大幅提前，即使汇总还没完成，也不至于干等。

第四，模型网关并发池化。云端API的HTTP连接复用、本地模型的并发队列、不同模型的统一超时配置，这些琐碎的事情集中到执行层的模型网关处理后，整体并发能力翻了一倍，失败率也降了不少。

7. 安全边界与审计设计：别把信任赌在模型自觉上

7.1 权限必须在代理层执行，不能依赖模型遵守

我在早期版本里做过一件幼稚的事：在系统提示词里告诉模型"你没有权限查看预算数据，请不要向用户透露"。然后测试用户非常轻松地通过上下文注入绕过了这条限制。这个教训让我彻底明白：模型的指令遵循能力再好，也只是概率性的，而权限是确定性的安全要求。

现在的做法是，所有权限校验都在代理层强制完成。模型拿到的上下文中，根本不会出现它无权访问的数据；模型请求写入的信息如果超出权限范围，协同层会直接拦截。模型不需要"自觉"，因为它压根没有机会接触不该碰的东西。

7.2 危险操作的四段式审批与审计日志

多AI协同系统里的危险操作，常见的有执行代码、覆盖文件、对外发送消息、申请调用外部支付接口。我的系统对这类操作统一走"类人审批"流程：代理提交一条操作意图，附上生成该意图的上下文摘要；相关权限人看到后批准或拒绝；批准后系统才执行；执行结果回写并留档。

对应的审计日志必须是四段式对齐：用户的原始指令是什么、代理将指令改写成了什么、模型最终生成了什么、系统实际执行了什么。这四段缺一段，出问题时责任就说不清。我遇到过好几次用户投诉"AI乱改文档"，最后靠四段式日志还原出其实是某个模型把用户原始描述里的"稍微改一下措辞"理解成"全面重写"——是改写环节的问题，不是执行环节乱来。

7.3 对模糊请求默认拒绝

协作者多的时候，用户发消息经常是惜字如金。如果用户的请求权限模糊、目标不明确、涉及范围不清楚，代理的默认动作不是"猜一个最可能的意图去执行"，而是向用户确认。这个原则看似保守，实际上救了很多次场。

有一次用户A说"把那个文件改一下"，没有指定哪个文件、改什么、改完给谁看。如果代理自作主张选了最近编辑的文件，极有可能覆盖了用户B正在修改的新版本。默认拒绝不是让系统变迟钝，而是让系统形成一种"确认成本远低于修复成本"的协作习惯。

我个人的体会是，协同系统的信任底线建立在"可解释、可干预、可回滚"三个词上：每一次自动决策都有日志解释理由，每一个关键节点人类都能随时介入喊停，每一次误操作都能快速回滚到上一个稳定状态。守住这三条，哪怕AI模型本身偶尔犯傻，系统整体仍然可控。这套多人多AI协同架构目前还在持续迭代，下一步我想把仲裁规则从静态配置改成可学习的动态策略，让系统在积累足够多的历史裁决案例之后，能辅助人类更快地处理那些今天还需要人工兜底的冲突场景。