本节摘要:用户智能体不是用户本人,而是用户派驻会场的代表:它把一句话需求翻译成执行侧能领会的议题,在过程中负责纠偏,在收尾时负责验收。本节讲清它的三项职责、它在 OWL 角色扮演架构里与执行侧的对话方式,以及"把用户智能体当哑巴传声筒"这一最常见误用的修正办法。
本节处于全册知识地图的"与会名册"第一站:上一章你认识了会议的流程与桌型,从本节起逐个认识坐在桌边的人。理解用户智能体的关键是先接受一个设定——真实用户在整场会里只出场一次(提交任务),剩下全程由这个代表代理出席。
直觉上,用户已经写好了任务描述,为什么还要一个智能体来"转达"?原因有三层。
第一,自然语言需求是漏的。"帮我调研一下竞品"这句话,漏了对象范围、时间范围、成果格式、验收标准。执行侧直接开工,就会按自己的默认值补全这些空缺——补错了,回头发现时已经烧掉大半轮次。用户智能体的第一职责是在对话开场就把空缺问出来、填上去。
第二,用户没有耐心全程在场。一场会跑几十轮对话,真人不可能每轮盯梢。代理的职责是在关键节点替你表态:这个中间结果符合意图吗?方向跑偏了吗?该喊停吗?
第三,意图需要被持续看守。执行侧在长任务里会不知不觉"偷换目标"——比如把"调研竞品定价"悄悄变成"罗列竞品一切信息"。甲方代表的存在,就是让每一阶段产出都过一遍意图核对。
OWL 的协作主轴是一对角色扮演对话。用户智能体拿到你的原始需求后,第一轮发言就是"任务制定":把需求转写成一条带上下文与验收标准的议题,交给执行侧表态。看一段最小代码,注意系统提示词怎么定义这个角色的行为边界:
from camel.agents import ChatAgent # 甲方代表:只管意图与验收,不教执行细节 user_agent = ChatAgent( system_message=( "你是调研任务的甲方代表。你的职责:" "1)把发起人的需求转写成明确的议题;" "2)对每份阶段产出核对是否符合原始意图;" "3)发现跑偏立即指出并给出纠偏方向。" "禁止:替执行方决定使用什么工具或步骤。" ) ) # 原始需求只有一句话 raw_request = "帮我看看我们竞品的定价" response = user_agent.step( f"发起人需求:{raw_request}。请转写成正式议题," "要求补全:调研对象范围、要回答的问题、成果格式。" ) print(response.msgs[0].content) # 输出示例: # 正式议题:调研竞品A、B、C三款产品当前官网公示的三档订阅定价, # 回答两个问题:1)与我们的定价差多少;2)定价结构差异反映了什么 # 功能取舍。成果格式:一页对比纪要,含差价百分比。
对比一下:原始需求是八个字级别的模糊句,议题补出了对象、问题清单与交付格式。这就是甲方代表的产出——它不干活,它把"活儿是什么"钉死。
甲方代表的纠偏分两类,混用会导致会议议而不决:
def classify_feedback(deviation: str) -> str: """按偏差性质分类纠偏粒度,避免甲方代表误伤整场会。""" topic_level = ["对象错了", "问题问错了", "范围不对", "目标变了"] quality_level = ["数据不全", "格式不符", "口径不一致", "漏了基期"] if any(k in deviation for k in topic_level): return "方向纠偏:要求重排议题,退回拆解阶段" if any(k in deviation for k in quality_level): return "质量纠偏:仅要求重做当前子任务" return "先与执行侧澄清偏差性质,再决定粒度" # 输出: # classify_feedback("口径不一致,两个竞品用了不同计费周期") # -> '质量纠偏:仅要求重做当前子任务' # classify_feedback("对象错了,我们要对比的是续费率不是定价") # -> '方向纠偏:要求重排议题,退回拆解阶段'
我见过最多的误用,是让甲方代表凭"感觉"验收:"看看这份报告好不好。"这等于把验收变成另一场玄学讨论。正确做法是把验收标准写进议题本身,验收时逐条对表:
acceptance = { "对象": "竞品A、B、C三款", "问题": ["差价百分比", "定价结构与功能取舍的对应"], "格式": "一页纪要,含对比表", "基期": "统一按月付年费折算", } def accept(deliverable_summary: dict) -> list: """逐条对表验收,返回未达标项。空列表即通过。""" misses = [] for key, rule in acceptance.items(): if key not in deliverable_summary: misses.append(f"缺少项:{key}") elif deliverable_summary[key] != rule: misses.append(f"{key} 不符:要求{rule},实际{deliverable_summary[key]}") return misses # 输出: # accept({"对象": "竞品A、B", "格式": "两页报告", "基期": "按月付月费"}) # -> ['对象 不符:要求竞品A、B、C三款,实际竞品A、B', # '缺少项:问题', # '格式 不符:要求一页纪要,含对比表,实际两页报告', # '基期 不符:要求统一按月付年费折算,实际按月付月费']
⚠️ 最常见的坑是把用户智能体写成第二个执行者:让它去想"应该用哪个搜索引擎"。一旦甲方代表开始管工具,角色扮演对话就退化成两个执行者互相指挥,会议立刻议而不决。修正办法就在系统提示词里写明"禁止替执行方决定工具与步骤"。
回到贯穿案例。第 4 章完整跑会时,甲方代表在三个时刻出场:
变式:如果你代表的是多干系人(产品、法务都有关切),可以让用户智能体在开场议题里显式列出各方关切清单,验收时逐方对表——这是把"会外拉扯"变成"会上议题"的最省事办法。