企业官网建设流程全解析

我之前深有体会：做人机协作类的研究，最难受的不是算法效果不好，而是出了问题时你根本说不清楚“到底哪一环出了错”。模型是个黑盒，用户也说不清自己的预期，两边明明在做一个任务，最后却像在隔空对话。最近读到一篇论文，标题很直白，叫《走向可靠的人机协作——构建基于共同基础的显式世界模型》，虽然篇幅不长，但它一下把我过去几年踩过的坑都串起来了。这篇论文的核心主张其实就一句话：想让机器和人协作得可靠，就不要让系统偷偷在心里建模，而是要把模型摊开，让双方共享同一个“世界描述”，并且持续对齐彼此的理解。这个思路不只是在学术上成立，在实际系统里也非常有操作价值。下面我结合自己的复现经验和工程化思考，把论文的拆解、落地路径、常见问题一次性讲清楚。

1. 为什么可靠的人机协作需要显式世界模型

1.1 从“模型不可见”到“模型可见”

先说一个很反直觉的现象：过去几年，不管是对话系统、具身智能还是办公自动化里的智能体，大家都在追求端到端、追求大模型隐式推理。隐式模型的好处是灵活，但代价是“不可观测”。用户压根不知道系统当前认为“目标是什么”“我已经完成了哪一步”“你刚才那句话被我理解成了什么”。

这种感觉就像跟一个水平很高但特别沉默的同事合作：他可能能力很强，但你永远不清楚他下一步要干嘛，也不清楚他有没有误解你的意思。一旦任务出岔子，你连从哪个环节开始复盘都不知道。论文里说的“显式世界模型”就是把这位沉默同事的内心活动打印出来，让他的“脑内小剧场”变成双方都能看到的共享屏幕。

这个转变听起来简单，实际操作里牵涉到表征方式、同步节奏、交互协议等一系列设计选择。论文给了很清晰的取舍方向：可解释性优先级高于参数灵活性，共享可见性高于单侧推理能力。这么做不是不要模型能力，而是把能力放在显式结构之上，而不是完全藏在参数里。

1.2 “共同基础”这个概念到底在解决什么问题

“共同基础”（Common Ground）这个词其实是从人类沟通研究里借来的。两个人在对话时，并不是把字典里的词义搬到对方脑子里，而是通过确认、反问、重复，逐步建立一个“你我知道我们都认同”的信息集合。比如你说“把那个蓝色的拿过来”，我会确认一句“是桌上的蓝色杯子吗”，你说“对”，这时“蓝色杯子”才进入我们的共同基础，而不是只存在于你一个人的意图里。

放到人机协作里，共同基础就是“人类与系统当前都认可的事实、目标、分工和约束”。论文反复强调的一点是：共同基础不等于“系统所知道的信息”，也不等于“用户说出来的内容”，而是双方交集之外再加一层“互知”——不仅我知道，你我知道，而且我知道你知道。如果没有这层互知，系统即使猜对了用户意图，用户也不知道它猜对了，依然会不安、不信任、重复确认。

可靠的人机协作真正缺失的并不是推理能力，而是这种“互知状态”的显式维护。模型知道归知道，还得让用户知道“你知道”，并且让模型知道“用户知道”。

1.3 显式表征带来的三类直接收益

把世界模型显式化之后，最直观的收益有三个。

第一，可调试性。系统在某个环节突然给出错误动作，我们不再需要从头跑日志、翻中间表征，而是直接看世界模型里“哪个状态数据错了”“哪条约束被遗漏了”“哪条用户指令被错误解释”。这就像代码出问题了能断点调试，而不是只能靠打印崩溃日志猜。

第二，可干预性。如果用户发现系统理解偏了，可以直接指着模型里的某一条说“我指的不是这个，你改一下这里”。显式模型给用户提供了一个可操作的“纠偏接口”，而不是只能重新说一遍话或者重置整个会话。

第三，可评估性。无论是离线测试还是在线人工评估，我们都能把“模型当前状态”和“真实环境状态”做逐项对比，算出到底在哪个维度上发生了偏差。这样，“可靠性”就不再是用户问卷调查里的抽象分数，而是一个可以被拆解、被度量的工程指标。

2. 论文核心设计拆解：共同基础上的世界模型结构

2.1 世界模型的分层结构

论文没有把世界模型设计成一个扁平的大表，而是分了几个层次，这个设计很符合实际系统的组织方式。

最底层叫“原始状态层”，负责记录环境里可感知的实体和属性。比如室内协作里是桌上有几个物体、物体在什么位置、哪个门是开着的，放在仓储场景就是货架编号、库存数量、搬运状态。这一层尽量贴近传感器原始输出，只做初步结构化，不做高层推测。

往上一层叫“任务状态层”，记录当前任务进行到哪一步。任务被拆成计划节点，每个节点有未开始、进行中、已完成、已阻塞等状态，还会记录每个节点是否依赖前置条件。这里其实就是在把“目标分解”这件事显式化，让用户随时能看到系统把大任务拆成了什么样子。

最上层叫“共识状态层”，专门维护“用户和系统共同认可”的内容。它不直接记录物理世界，而是记录诸如“用户同意先完成A再完成B”“系统已向用户说明无法执行C”“用户确认D位置的物体可以移动”这类协调性信息。这三层之间不是孤立的，每次任务状态更新、每个原始感知变化，都可能触发共识层的确认与对齐。

2.2 共同基础的形式化协议

光有分层结构还不够，还得有一套协议来定义“什么信息能进入共同基础”“什么信息只是单方面推测”。论文提出的思路是给每一条模型断言加上“模态标注”和“置信状态”。

模态标注最重要的一点是把“事实”和“推测”区分开。事实类断言来自传感器或者用户的明确陈述，推测类断言来自模型推理。比如“当前桌上有一个蓝色杯子”是感知事实，“用户可能想让我把杯子端起来”就是推测。推测在没有经过用户确认之前，绝对不能直接进入共识层。

置信状态则用于处理不确定性。系统可以用 0 到 1 的数值表示一条断言的确定程度，但这个置信度不是只给系统自己看的，而是同步展示给用户的。用户看到系统对某个目标“只有 60% 的把握”，会自然而然给出额外解释或者纠正，这比系统假装自信要有效得多。这也是显式模型最有意思的地方——不确定性本身也可以成为沟通内容。

2.3 对齐与更新机制

共同基础不是一次性建好就不动了，它需要持续“对齐”。论文里的更新机制有点像 git 的同步流程：系统每次产生新的断言，先放进“候选区”，只有经过确认才能合并进“共识层”，确认方式可以是用户明确的“对/不对”反馈，也可以是系统主动发起询问“你是指这个吗”，还可以是用户直接修改模型内容，比如编辑一个目标节点的描述。

这套机制还有一条关键规则：任何一方发现共同基础里的内容与事实不符，都有相同权利发起“修订提案”。不是只有系统可以更新状态，用户也可以。这个设计保证了协作关系不是单向“系统服务用户”，而是双向共建。实际工程里，这个“共同基础编辑器”的交互设计往往决定整个系统好不好用。

3. 从论文到系统：实操落地步骤

3.1 场景与任务定义

如果只停留在概念层面，这篇论文的价值会大打折扣。我在自己设计的一套模拟协作任务系统里试过这套思路，用的是小型桌面协作场景：用户和智能体一起整理桌面物品，用户用自然语言下发目标，系统负责规划并执行部分动作。这个场景麻雀虽小，五脏俱全——有感知、有规划、有指令理解、有动作执行，非常适合验证共同基础机制。

建议你也选一个能快速搭建模拟环境的场景，核心条件有三个：环境状态可编程控制、用户指令可以自然语言输入、系统动作能实时渲染展示。这三个条件满足之后，相关机制就可以稳定复现。

3.2 世界模型与共同基础的数据结构设计

这一步是代码层面的地基，我直接给出我实际使用的结构。

原始状态层可以就是一个 JSON 对象数组，每条记录包括实体 ID、类型、属性键值、最近更新时间。

world_state = [ {"id": "obj_001", "type": "cup", "attrs": {"color": "blue", "x": 12.0, "y": 30.0}, "updated_at": 12345} ]

任务状态层用任务节点图来表示，每个节点有前置条件、后置条件和执行状态。

task_graph = { "nodes": [ {"id": "t1", "desc": "把红色物品放到篮子", "status": "in_progress", "dependencies": []}, {"id": "t2", "desc": "把篮子移到左桌角", "status": "waiting", "dependencies": ["t1"]} ], "goal": "完成桌面整理" }

共识状态层是这套系统里最特别的部分，每条记录除了内容本身，还带有来源、确认状态和互知标记。

common_ground = [ { "content": "用户要求先整理红色物品", "source": "user_statement", "confirmation": "confirmed", "mutual": True, "confidence": 1.0 }, { "content": "系统建议先完成t1再执行t2", "source": "system_proposal", "confirmation": "pending", "mutual": False, "confidence": 0.8 } ]

这里互知标记 True 表示“不仅我知道，你也知道我知道”，它和确认状态密切相关。如果某条内容是系统单方面推测，那么 mutual 必须是 False，直到用户给出反馈后才能置为 True，这个细节特别容易被忽略。

3.3 交互循环中的同步机制

系统主循环可以设计成“感知→建模→提案→确认→执行”五步循环，每一步都有机会把状态同步给用户。

感知阶段把环境数据更新到原始状态层，建模阶段基于感知结果和当前共识状态生成候选断言，提案阶段把候选断言展示给用户。这里可以采用两种展示方式：一种是主动询问，像对话框里弹一条“我注意到桌上有一个蓝色杯子，需要移动它吗”；另一种是漂在界面里的状态卡片，系统直接把候选内容放在显眼位置等待用户确认。如果用户在一定轮数内没有反馈，系统不应该把这条内容悄悄转正，而是维持 pending 状态并降低执行信心。

确认通过之后才进入执行阶段，碰到需要调用模型做指令理解或者动作规划的情况，这个判断也一定要落回显式状态，不要让模型输出的结果直接改写世界模型，必须先经过一轮状态校验再合并进去。市面上很多系统的通病是，模型说什么就是什么，最后用户都不知道状态是哪来的。

3.4 可靠性评估怎么设计

论文里最实在的部分，我认为是它把可靠性评估拆成了几个可以量化的维度，而不是笼统说“准确率高”。

第一维度是状态准确率：世界模型里的每条状态记录，跟真实环境状态比，一致的比例是多少。这个指标需要用预置的环境脚本来算，每轮跑完自动对比。

第二维度是对齐效率：用户需要多少轮对话才能把一条关键指令完全对齐到系统任务状态。比如“把红色物品放到篮子”这条指令，如果系统一次确认就懂了，对齐成本是 1；如果连续问了三轮才懂，对齐成本就是 3。这个指标直接反映系统的沟通效率，对用户体验影响很大。

第三维度是干预成功率：用户在用户界面上手动修改世界模型后，系统后续的行为是否真的按照修改后的模型执行。如果用户改了状态但系统还是按旧状态跑，那所谓的“可干预”就只是个摆设。测评时我专门设计了错误场景，逼着用户去改模型，再看后续动作是否修正。

这三个维度加上传统的任务完成率，基本可以构成一套完整的人机协作可靠性评估体系，不亚于任何现成的端到端评测方法。

4. 复现过程中的高频问题与排查笔记

4.1 问题一：共同基础漂移

我遇到最频繁的问题，是共同基础内容渐渐跟事实脱节。原因通常是系统长期没有收到用户反馈，却仍然基于旧共识做新推测，导致推测一层层叠上去，每层都不是用户确认过的。举个例子，用户一开始确认了“优先整理红色物品”，后来任务临时变了，用户没有明说，系统却基于旧共识推断用户还是想要红色优先，后面所有提案都歪了。

排查思路很简单：把所有带有 confirmed 标记的共识条目按时间排序，看看时间戳是否离当前太远。一旦发现某条共识已经超过整个任务的时长的合理比例，就要触发重新确认。我自己会在共识层加一个自动过期机制，超过预设轮数便自动把状态从 active 降为 stale，系统再次提出新提案时就必须先把这个旧条目重新确认一遍。

4.2 问题二：同步开销大到用户烦

显式模型的代价，就是沟通次数增加。我最初实现时每个状态变化都要发起确认，任务还没做两步，用户已经被问烦了，实验室的几位朋友试用时直接说“这东西太啰嗦，还不如我自己干”。

后来我参考了论文里关于“默认信任”的讨论，做了一个分级确认策略：高置信度、低风险、可撤销的动作，系统只展示不等待，直接执行；低置信度、高风险、不可逆的动作，系统必须弹出确认框；中等情况则提供一键确认按钮。这样把同步开销控制在用户可接受的范围内，可靠性也没有明显下降。这里我想强调一个原则：显式世界模型不是越频繁越好，而是在关键分岔口把状态摊开，让用户兜底，其余时候保持轻量。

4.3 问题三：用户不信任系统，甚至不敢改状态

理论上用户可以直接修改世界模型，但实际测试里发现，很多人并不知道自己有这个权限，或者即使知道也不敢动。这里有一个交互上的隐性门槛：系统只是在界面角落放了一个“编辑状态”按钮，用户根本感知不到它跟当前任务的关联。

解决办法是在系统产生理解分歧时，主动把“修改入口”带到对话流程里。比如当系统准备执行一个提案时，界面同时展示“我可以修改此项”，用户点进去看到的不是抽象的状态字段，而是通俗的任务条目列表。我还为每一条共识加了来源标签，用户可以轻易看到这条状态来自“用户的原始表述”还是“系统推测”。这一步设计彻底打开了用户对系统的信任感，因为他们发现自己不用对抗系统，而是可以直接参与修正。

4.4 问题四：评估指标互相矛盾

刚开始跑评估时，我发现状态准确率很高，任务完成率也很高，但用户主观评分却很低。后来复盘才意识到，问题出在“准确率高只能说明模型的记录对了，不说明协作过程顺”。系统可能自己做完了任务，但用户全程觉得自己被晾在一边，状态准确率再高也没有意义，用户觉得你们没有在协作。

这个问题让我改进评估体系，增加了“过程质量”指标，比如用户追加干预次数、用户主动发起确认次数、用户在关键分歧点的等待时间。真正可靠的人机协作必须是“结果对，过程也透明”，两者缺一不可。

4.5 高频问题速查表

5. 我的几点实践经验与扩展思考

5.1 关于沟通的颗粒度

这次复现让我最受用的一个认知是：可靠性并不来自模型本身的规模和能力，而是来自“沟通颗粒度”。信息粒度如果太粗，只说目标不说步骤，很容易在执行中产生分歧；信息粒度如果太细，每一步都要解释，沟通成本又会高到让人放弃。真正好的设计是根据当前动作的风险等级动态调整颗粒度，风险高时多解释、多确认，风险低时快速带过。这跟人与人之间协作的行为模式几乎一致，靠谱的同事不会每一步都问你，但会在关键决定前跟你通个气。

5.2 这个方向还能怎么做扩展

论文的框架看起来很完善，但真正落地时还有几个我可以看到的延伸方向。

一是把共同基础从“文字描述”扩展到“多模态指称”。现在的状态条目基本是文本字段，未来可以让用户直接在画面里点选物体、圈选区域，把视觉指代也纳入共识层，这种方式对复杂的空间协作任务特别有想象空间。

二是引入大模型作为“共识翻译器”。显式世界模型结构清晰，但让普通用户直接写结构化状态还是太费劲。可以做一个语言入口，让大模型把用户的随意表达转成候选共识条目，再走确认流程。这样既保留了显式结构的可解释性，又吸收了大模型理解能力，两条路线都能兼顾。

三是做“共同基础历史”的长期记忆。当前实现只维护当前任务内的共识状态，如果同一个用户多次协作，就可以把过往共识沉淀成偏好规则。用户在这套机制里表达过“优先安全而不是效率”或者“不要随便移动我的文件”，下一次协作时系统就能把这些历史共识当作先验条件，减少重复对齐成本，但也随之带来“旧共识是否仍然可靠”的新问题，值得深入研究。

按我个人的体会，这篇论文最打动我的不是某一条具体的算法，而是它把“可靠性”从一句口号变成了一个可设计、可调试、可评估的系统属性。哪怕你暂时不做世界模型这方面的研究，这套“显式化 + 共同基础 + 分层共识”的思维框架，也值得放到任何一个人机交互项目里试试。最后再分享一个小细节：后来我把这套系统拿给几位完全没有论文背景的朋友试用，他们看完界面后说的第一句话基本都是“它懂我在想什么”，这几句反馈比任何评估分数都更能说明问题。