企业官网建设流程全解析

把一次 AI 聊天的最终页面截图发给同事，可能是这两年我看到最频繁、也最浪费价值的同步方式。你拿到了结果，丢掉的是过程；而在 Elastic Agent Builder 这类能对接检索和工具调用的代理平台里，过程往往比结果重要得多。今天我专门聊聊如何在 Elastic Agent Builder 里用实时共享对话替代截图协作，包括底层机制、完整操作步骤、我自己踩过的坑，以及几个从团队协作到对外演示的真实场景。如果你是正在搭 AI Agent、又苦于没法跟产品、测试、客户同步中间过程的开发者，这篇应该能让你少走不少弯路。

1. 从图片到活会话：为什么截图式协作早该淘汰了

1.1 截图协作的三个致命痛点

我先说一个特别典型的场景。三周前我负责调一个内部知识库问答代理，代理的回答不太对，我把聊天界面截图发给了某个后端同事。他回了一句：“它检索到了什么？为什么它会这么回答？”我愣住了——截图里只有最终答案，没有任何中间过程。

这是截图协作最核心的问题：它只记录了结果，不记录上下文。就拿 Agent Builder 里的常见配置来说，一个代理要回答用户问题，通常要经历“改写问题 → 检索索引 → 拼接上下文 → 推理 → 生成回答”这一串流程。如果最终回答不对，问题可能出在检索环节召回错了文档，也可能出在系统提示词把优先级带偏了，或者模型根本没用好召回的内容。这些中间状态截个图根本看不出来，你只能重新跑一遍、手动把若干中间结果贴进聊天框，然后再截更多图。一次协作变成一场猜谜游戏。

第二个痛点是对话不可继续。把截图发给人，对方只能看到“过去式”。他想换个问法、调一下参数、看某个分支回答，就必须从零开始新建会话，自己重新输入系统提示词、重新选索引、重新配置。真正要协同调代理的时候，大家需要的不是看图，而是上手——在同一段上下文里继续提问、继续验证。

第三个痛点是工具调用过程不可见。RAG 代理和普通聊天机器人的最大区别就是会动“手”：查数据库、调用外部 API、读取文档。这些工具的操作结果、报错信息、耗时数据，都是排查问题的一手证据。截图只截最终对话框，这些证据全部丢失，等于把故障现场清理干净了再给人看照片。

1.2 实时共享会话和截图的本质差别

实时共享对话解决的不只是“把截图换成链接”这么简单，它把共享对象从“快照”变成了“活动会话”。

快照的核心特点是静态的；活动会话的核心特点是持续的。你分享出去的不是一个已经完成的对话记录，而是一个仍然在运行、仍然可以被参与者继续输入、继续观察、继续响应的聊天实例。参与者在链接里看到的不只是从前的消息，还能看到当前正在发生的流式输出、检索状态、工具调用情况。换句话说，共享出去的是一种“正在发生”的状态，而不是“曾经发生”的痕迹。

在 Elastic Agent Builder 里，这个差别被放大得非常明显。因为代理背后连着 Elasticsearch 索引、模型服务、工具接口，实时共享意味着所有参与者共同观察同一套检索后的上下文和推理过程，而不只是看到最后那几句漂亮的回答。这对验证代理行为、排查召回质量、确认系统提示词是否生效，价值是截图无法比的。

1.3 一句话总结：为什么要拥抱实时共享

不是因为花哨，而是因为省事。用截图分享，你要补多少背景解释；用实时共享，你只要发一个链接。对方可以自己玩，自己看过程，自己问问题，你的解释成本直接降一个数量级。

2. 实时共享是怎么做出来的：会话事件流与状态同步

2.1 Agent Builder 里的会话不只是“聊天记录”

很多人对实时共享的实现机制一头雾水，以为就是把聊天记录同步成在线文档。真实情况会比这个复杂一层。在 Agent Builder 这类代理平台里，一个会话包含以下几个层面的信息：

• 用户消息序列：每次提问和回答的文本记录；
• 检索过程信息：代理命中哪些索引、召回哪些文档、每个文档的相关度分数；
• 工具调用记录：调用了哪个工具、传入了什么参数、返回了什么结果；
• 模型调用详情：使用了哪个模型、输入了多少 token、输出了多少 token、耗时多少；
• 会话状态：当前代理配置版本、上下文窗口内保留的临时变量、记忆内容。

实时共享的核心任务，就是把这五个层面的信息打包成持续更新的状态，并及时推送给所有被授权看到这个会话的人。如果只同步第一层“聊天文本”，那和共享一个在线聊天文档没啥区别，对排查问题帮助有限。Agent Builder 的实时共享做得更有价值的地方，在于它会同步完整的代理运行轨迹。

2.2 事件流而不是消息列表

我理解这种实时共享的技术底座，通常不是简单地同步一个 JSON 消息数组，而是按“事件流”来同步。每个会话都是一串有序事件，例如：

question_submitted query_rewritten search_triggered search_results_returned context_assembled model_invoked partial_output tool_call_started tool_call_finished answer_completed

前端界面会订阅这些事件，于是参与者能看到“代理正在检索”、“检索完成，命中 12 个文档”、“正在调用某某工具”这些实时状态。这比等最终答案一下子刷出来要直观得多，尤其当代理链路长、涉及多个工具时，参与者能清楚看到它正卡在哪一步。

事件流带来的另一个好处，是消息的顺序一致性。因为每个事件都带序号，不同参与者看到的排列不会乱。你在左边浏览器看到第 28 个事件，别人在右边浏览器看到的也是第 28 个事件。排查问题的时候，大家能精确地对齐每一步。

2.3 三种参与角色：owner、editor、viewer

实时共享不是拉个群、所有人都可以随便提问那么简单。我对权限模型的总结是：粒度一定要细，否则共享会变成安全事故。

在常见实现里，会话参与角色至少分成三种：

我看过不少团队分享代理会话时一刀切，所有拿到链接的人都能提问，结果客户在演示链接里乱调接口，把测试环境搞得乌烟瘴气。合理的做法是：默认给 viewer 权限，需要交互时才升级为 editor，owner 永远只有一个人。

2.4 状态同步和断线恢复

实时共享还有一个容易被忽略的技术细节：断线恢复。参与者可能关掉浏览器、换网络、后台切线程，重新打开时，前端要能通过拉取“增量事件”把错过的部分补回来，而不是整个会话重新加载一遍。

这里有一个很常见的坑：如果共享链接只是用 WebSocket 推消息，断线重连后很容易丢最后的几帧。严谨的做法是把 WebSocket 流和事件快照结合起来——进入时先拉一个快照，然后订阅增量，这样既能看到历史，也不会漏掉进行中的状态。

3. 实操流程：在 Agent Builder 里把一次对话变成可参加的实时会话

3.1 从构建代理开始

实时共享的前提是先把代理本身配置好。这个不在本文详述，但至少你要确认几件事：

• 代理已连接到可用的模型服务；
• 至少绑定了一个 Elasticsearch 索引作为检索源；
• 系统提示词写清楚代理的职责边界；
• 工具调用已配置并测试通过。

完成这些之后，进入代理详情页或会话管理页，能看到一个“创建会话”或“开始对话”的入口。在这个页面里你可以先自己发起一轮问答，确认代理行为符合预期。这里的重点在于：只有这个会话处于“活跃”状态时，共享才有意义。会话如果已经关闭，那么共享出去的就是一份普通历史记录，而不是实时会话。

3.2 打开共享并设置访问策略

在会话进行中，找到“共享”或“邀请”入口。这时一般会弹出几个选项：

• 参与者角色：默认所有人都是 viewer，可以单独提升；
• 访问时限：半小时、一天、一周、永久；
• 是否需要审批：允许任何人凭链接加入，还是要求加入请求必须由 owner 批准；
• 是否开放提问：关闭后参与者只能看，不能输入。

我个人的实操顺序是：先按“需要审批 + 仅查看 + 短时限”生成链接，发给一两位核心同事试用，确认没问题后，再根据场景调整角色和时限。不要一上来就用“永久 + 任何人都可编辑”的组合，这是实时共享最容易翻车的配置。

3.3 生成并发送共享链接

设置完成后，系统会生成一串链接。常见的三种使用方式：

1. 直接复制链接，发到团队沟通群；
2. 通过 iframe 嵌入内部知识库或其他管理页面；
3. 生成带过期时间的短链接，用于对外演示。

第一种最常用，适合日常协作。第二种适合把代理会话嵌进团队已有的看板或文档平台，让代理使用的过程随时可见。第三种适合交付演示，客户点开链接就能看到代理在你预设的会话里回答问题，还能亲自上手试。

如果你在对外演示时不想暴露内部会话的完整上下文，可以只开放一个新建的空会话，把代理配置好、提示词固定好，再让客户在里面自由提问。这比截图展示“预设好的漂亮回答”有说服力得多。

3.4 配置参考清单

下面这份清单是我整理出来给团队用的，照着勾一遍基本不容易漏：

• 模型连接：确认 API Key 有效，剩余配额足够支撑共享期间的提问量；
• 索引权限：确认代理所用的服务账号对索引有读取权限；
• 系统提示词：写清楚“你能做什么、不能做什么、遇到不确定时怎么办”；
• 共享角色：明确谁是 editor、谁是 viewer；
• 过期时间：短演示设一小时以内，长期协作设一周并设置提醒；
• 审批开关：对外开放时打开审批，避免陌生链接被滥用；
• 审计日志：开启操作记录，方便事后追溯谁在共享会话里做了哪些动作。

4. 三个真实场景：实时共享把我的协作方式改成了什么样

4.1 团队评审：让测试、产品、后端在同一个会话里一起较劲

以前评审代理，大约流程是：我先跑一轮 demo，截图发群里，大家看图提意见，我回去改完再截一轮图。这个循环特别慢，而且意见经常基于“对截图的理解”，不是基于真实行为。

现在改用实时共享，流程变简单了。我把一个会话以 editor 权限共享给参与评审的团队成员，每个人在同一个会话里连续提问。测试同事专门挑刁钻句式，产品同事关注回答是否符合话术规范，后端同事则盯着检索事件，看代理有没有搜到合理的内容。所有人在同一个会话里看到的是同一套过程，讨论时可以直接说“刚才你问的第三轮，代理检索出来的前两条其实不太相关”。这种讨论质量，截图永远给不了。

这里最重要的变化是：代理的迭代思路在共享会话里被完整保存下来。评审结束后，整个会话就是一个带着提问、检索、回答全过程的可追溯记录，比会议纪要详细得多。

4.2 调试：观察代理每一步决策，而不是只看最终答案

有一回代理回答一直带着从某份旧文档里抄来的过时数据。我一开始怀疑模型幻觉，后来发现根因在检索环节。真正帮我定位问题的，是共享会话里完整呈现的检索事件——我看到代理把一条早已失效的文档也召回了，并且相关度分数还不低。

实时共享在调试时的价值就是这么快。参与调试的人不用跑到你屏幕前围观，也不等截图。他直接在共享会话里看检索事件流，发现哪一步不对劲，当场就指出问题，你这边马上调整代理配置再试一轮。整个调试过程从“来回传图”变成“共同观看进行时”。

4.3 对外演示：客户不再看 PPT，而是亲自动手提问

过去给客户演示 AI 功能，基本是播放准备好的录像或截图，客户看完觉得“哦，你做得挺好”。但它有个致命问题：客户无法验证代理是否真的能用。

后来做了一次现场演示，我用实时共享把代理会话链接发给客户，让客户自己输入他们业务里的真实问题。代理现场检索、现场回答，客户能看到每一步。那次演示之后，客户对方案的接受度明显提升。因为真实提问现场生成回答，比任何精心准备的截图都有说服力。

当然，对外演示要把安全隐患堵死。我的做法是：单独建一个演示专用代理，用独立索引、独立模型密钥，共享链接设置一小时内过期，参与者只给 viewer 权限。如果有交互环节，最多给 editor，绝不给 owner。

5. 共享的每一轮对话都在花真金白银：权限、用量、生命周期管理

5.1 共享不等于放开访问控制

我见过一个反面案例：某个团队把一个代理的共享链接设成“永久有效、任何人可编辑”，还直接发到了公开群里。结果代理的模型额度两天被刷光，索引也被大量无用查询打满。这不是实时共享功能的问题，是权限管理的问题。

实时共享链接本质上是一把钥匙。钥匙发出去，任何人都能在你授权的范围内操作。所以有三条纪律要立住：

• 能只读就绝不开放提问；
• 能短时限就不设永久；
• 能加审批就不允许随意加入。

特别是对接了付费模型服务的代理，每多一次共享提问，就多一笔 token 费用。开放得太随意，月底账单会教你做人。

5.2 会话生命周期：该关就关，别留着

代理构建完成、评审结束、演示做完之后，我建议主动把共享会话关闭，而不仅仅是改权限。因为长期开放的会话会占用内存态状态、保留上下文变量、持续接收事件流，既不经济，也增加被翻旧账的风险。

我在实际使用中形成了一套生命周期规则：

• 短协作：会话当天关闭；
• 评审周期：评审结束后一周内关闭；
• 对外演示：演示结束立即收回；
• 长期复盘：把需要保留的会话归档为只读，不再接受新提问。

关闭会话后，历史消息通常还可以通过审计日志查看，但不会再产生新的模型调用，也不会实时推送给参与者。

5.3 用量监控：给共享行为加上仪表盘

在 Elastic Agent Builder 这类平台里，一般可以查每个会话的 token 消耗、调用次数和耗时。我建议把“共享会话”单列为一类监控维度。如果某一天 token 消耗异常上涨，大概率是被共享出去的某个会话被人高频使用了。这时候要做的是：拉出该会话链接，确认是否还在有效期内，必要时立即收回。

你也可以设置每日/每周用量的提醒阈值，比如“单日会话调用超过 200 次就报警”。这不是多此一举，代理上线之后，共享会话调用量就是实际使用量的缩影。

6. 实时共享排查手册：链接打不开、延迟高、状态不同步怎么定位

6.1 共享链接打不开，先查权限链

收到“我打不开链接”的反馈，大多数情况不是链接坏了，而是权限链断了一环。我的排查顺序是：

1. 共享链接本身是否过期；
2. 用户是否登录了具备访问资格的身份；
3. 该身份是否被分配到允许查看此会话的角色；
4. 代理是否处于 active 状态；
5. 如果要求审批，owner 是否通过了这个访问者的申请。

有一回我怎么都查不到原因，后来发现问题是：共享链接绑定的身份体系和实际访问者使用的身份体系不是同一个，导致系统认为“用户不存在”。解决方法是确认所有参与者都使用约定的统一登录入口，不要混用不同来源的账号。

6.2 共享会话回复变慢，怎么看瓶颈

实时共享会话里回复变慢，可能原因很多。我的判断经验是：

如果代理在共享会话里同时被多人提问，还要考虑并发限制。很多模型服务是并发受限的，多个用户同时触发调用会导致互相等待。我实践中最直接的办法是错峰提问——在演示或评审之前，提前说清楚“大家逐个来，不要同时点发送”。

6.3 状态不同步：看到的消息顺序对不上

有用户反馈说，他们那边的事件总比我的落后几条。排查下来，问题基本出在事件重放机制上。如果断线重连后，前端只从最后一条消息开始拉增量，而中间错过的关键事件没有补全，就会造成“少了中间步骤”的错觉。

处理方式是：让前端在每次重连时执行一次快照对齐，从服务端拉取从最后确认序号到当前序号之间的全部增量事件，再更新界面。如果平台不自动做这件事，用户手动刷新页面通常能触发一次新的快照加载。如果你自己搭类似系统，这个“快照 + 增量”的同步方式值得一开始就设计进去。

6.4 共享会话里的操作日志去哪里查

当共享会话出了安全事故或行为异常，第一件事是查操作日志。日志里应该能看到谁在什么时间、通过哪个链接、以什么角色、执行了什么操作。如果日志缺失，说明平台配置里没有打开会话级审计。我强烈建议把会话日志当成重要资产来对待，不要等问题出现后再去后悔没开审计。

查日志的重点顺序也是固定的：先看操作时间点，确认是否存在非工作时段访问；再看操作对象，确认有没有越权修改代理配置；最后看工具调用记录，确认敏感工具是否被外部参与者误触发。这一套下来，百分之九十的共享会话异常都能定位到根因。

写在最后的一点体会

实时共享这个概念听起来不复杂，但真正用起来后，它会改变你协作的整个节奏。以前我和同事讨论代理问题，总要花大量时间先“把对背景的理解对齐”；现在大家点开同一个共享会话，各自看事件流，问题一下就对齐了。我被这个体验打动，也是因为它解决了一个特别朴素的需求：让所有关心同一个 AI 对话的人，不再靠图片猜过程。

如果你刚开始用 Elastic Agent Builder 的实时共享，我建议从最小范围开始——先开一个 viewer 权限的会话，拉上一位同事看十分钟检索过程，感受一下这种方式给你带来的信息量变化。等你习惯了在共享会话里看事件流排错，大概率就再也不想回到截图时代了。