不急着给用户贴标签，而是帮助他们说清关系期待。

参与项目初期，我从产品目标出发绘制整体 Agent 架构，组织知识、角色原则、行为、理解、对话策略、问题选择、回复和评价之间的关系。

当前重点推进关系知识架构 RKA；Character、Behavior、Reasoning／Formulation、Conversation Strategy 等后续具体设计也主要由我负责。

本页的阶段范围

• 已有设计产物： 初期整体架构，以及关系知识、回答处理、画像和探索方法规范。
• 持续细化： 角色、行为、理解与策略的具体要求；本页用设计实例解释它们怎样配合。
• 团队产品进度： 对话、画像与记忆已有使用记录；各项规范接入情况需按实际实现核对。
• 后续匹配： 正式推荐尚未开放，当前说明的是信息组织与使用要求。

本页聚焦我负责的 Agent 设计工作，不以阶段性展示替代完整产品的实现状态。

同一个标签可能代表不同期待。有人希望对方认真听，有人希望出现分歧时不回避，有人希望忙碌时主动告知。

团队从关系需要难以表达、双方是否适合难以判断的问题切入，面向香港年轻成年人探索产品方向。对话承担的任务，是帮助用户把概括性的期待说具体，再为后续关系理解与对象发现提供信息。

基础信息可以直接输入；需要联系情境才能解释的内容，适合逐步交流。采用 AI 对话也带来新的设计要求：控制提问负担、避免替用户归因、保留修正与停止。

1. 01建立起点
2. 02表达与澄清
3. 03查看和修正画像
4. 04决定信息用途
5. 05后续发现与持续更新

初次进入时，用户不必想清所有期待。交流中，Agent 根据当前信息判断是否需要澄清；交流之后，用户需要能看懂整理结果，指出不准确内容，并知道哪些信息将被公开或用于后续匹配。

设计的重点不是让画像尽快填满，而是让每一次交流留下够具体、可修正、用途清楚的信息。

整体架构从产品目标开始，连接八类工作：知识基础、角色原则、外显行为、情境理解、对话策略、问题选择、回复生成和评价。

知识帮助理解表达；角色原则约束判断；情境理解识别当前需要；策略决定下一步；问题选择和生成负责执行；用户的新回答再改变当前理解。

因此运行过程是循环决策，而不是从题库依次取问题。评价也需要回到上游，区分知识、判断、动作与表达分别出了什么问题。

我将关系知识组织为浅层、深层、适配和关系目标，再把每个 Topic 写成能够定位信息、理解回答和选择动作的规范。

Topic 实例：联系方式与线上互动

这个话题了解日常联系习惯、回复节奏、主动性、分享内容，以及对伴侣相关行为的期待。它不负责解释关系推进速度、情绪支持、账号隐私或冲突修复；这些内容分别关联其他话题，已有信息可以复用。

范围边界影响 Agent 怎么使用知识：用户说回复慢，先了解其情境，不能直接转成“感情冷淡”；用户谈到账号查看，也不应该继续按联系频率处理。

具体议题：联系频率、回复节奏与差异接受

我在这个议题中区分四件事：用户实际怎样联系、通常怎样回复、希望双方怎样联系，以及可以接受哪些差异。

原参考问题包括“平时不见面时，希望多久聊一次，忙碌时怎样调整”，以及“收到消息后，通常在什么情况下回复”。前者了解期待，后者了解自身习惯，答案不能相互代替。

回答怎样改变下一步

“忙时我可能晚上才集中回复。”

这句话提供了忙碌情境下的个人习惯。规范要求记录条件与做法，不由此推断用户冷淡、投入少，或要求伴侣采用同样节奏。只有联系说明会影响当前理解时，再补相关问题。

“不用秒回，但一天都没消息时希望能说明。”

这句话已经给出可接受的延迟与需要说明的情形。规范要求保留这个边界，不自行细化成两小时或半天的时限；当前目的已经清楚时可以停止。

Evidence 用来解决缺口，不是要求每个回答举证

用户明确表达一种期待时，可以按范围记录。只有“回复要及时”等说法仍然模糊，且差异会影响理解时，才需要具体情境。没有经历、没有明确要求或不愿讨论，也应保留其状态。

因此参考问题不是逐项必答清单。每一轮都先看已有回答是否够用，避免从知识覆盖面倒推用户还必须回答多少问题。

从议题规范到关系信息

这条期待需要保留原始表达、具体内容、所属话题、对象、忙碌等适用情境、条件强度和确认状态。它描述的是用户希望怎样相处，还不是双方已经达成的约定。

这些区别会继续影响后续用途：候选人没有说明回复习惯，不等于满足条件；用户尚未说某项是底线，也不能自动升级为硬性筛选。

这一 Topic 展示了我的设计重点：知识定义回答属于哪里，信息状态决定还缺什么，对话策略决定要不要追问，记录规则决定哪些内容可以用于后续产品功能。 它不是要求用户完成一套固定问卷。

在关系探索中，Agent 可以帮助澄清和组织表达，但不能把一次回答直接变成人格结论，或将用户自己的特点自动当作对伴侣的要求。

我在知识使用、画像与通用提问规则中区分直接表达、暂定理解和未知。用户可以修正、拒答或结束；深入探索需要考虑当前任务和意愿。

后续角色与行为设计会继续细化：怎样回应情绪，怎样提出不同意见，什么时候承认不知道，什么时候不再推进。角色语气需要和这些判断一致，不能只是写一段友好的人设介绍。

对话决策示例

用户：我想找一个会沟通的人。

Agent：你觉得对方怎样做，会让你感觉沟通是顺畅的？

用户：有分歧时愿意说清楚，不要直接消失。

第一次回答提出了抽象期待，当前缺少的是“会沟通”的具体含义。因此下一步是澄清，而不是立即推断用户的依恋类型或追问过去的创伤。

第二次回答已经给出情境与期待：出现分歧时，仍希望对方回应并共同讨论。Agent 可以总结并检查理解，而不是继续从题库抽问题。

Agent：你在意的是，有分歧时对方仍愿意回应，一起把事情讨论清楚。这样理解准确吗？

这段设计连接了几项工作：理解当前表达、识别重要缺口、选择澄清或总结、控制提问深度，以及让生成的回复只执行当前动作。用户如果否认，下一步应修正理解。

“重视沟通”或“联系频率低”这样的标签，会丢失情境。关系模型需要保存用户表达的具体条件，并区分自身行为、未来期待和双方安排。

画像文档中的一个更新实例是：原先理解为偏好低频联系，后来用户明确只是工作时不方便回复。这时需要修改的是适用条件，不能继续把“低频”当成全情境偏好。

我把信息变化分成补充空白、解释概念、增加条件、增加行为依据、修正理解与更新状态。新的内容不一定覆盖旧内容：工作时不便回复，与希望每天保持联系可以同时成立。

同样，期待不等于已有行为。原文的一组初始画像记录了用户希望每天联系、工作时不要求秒回，也记录其没有恋爱经历。这个状态可以支持继续了解，但不能据此认定用户已经善于沟通，或实际相处一定符合期待。

记录需要说明来源和确认状态。用户直接说出的内容按其范围保存，Agent综合形成的理解保持暂定；重复说同一段经历，也不能算新增多次独立依据。

画像准确与允许公开是两个决定。后续匹配还需要考虑内容是否被确认、允许怎样使用，以及对方信息是否足够。

相似性、吸引力和关系适配也不能直接等同。兴趣相近可以形成交流起点，但怎样回应、安排生活和协调差异，需要更多具体信息。

明确条件与一般偏好需要区别，未确认推断不能直接成为筛选依据；对方没有提供某项信息，也不等于已经满足要求。当前正式推荐尚未开放，这些设计为后续实现提供约束。

目前形成的架构、RKA、画像与对话方法，为团队讨论提供共同依据。后续需要继续将情境写成可以检查的预期：用户说了什么、已有信息是什么、应该采取什么动作、如何记录，以及哪些行为需要避免。

评价将关注信息是否复用、理解是否越界、提问是否必要、停止是否被尊重、画像是否可修正。重复提问可能来自没有保存、没有提供或没有使用已知信息，需要分别定位，才能决定改知识、状态、策略还是表达。

这段工作体现我对 Agent 的理解：从用户任务出发，定义它需要知道、判断、表达和记住什么，再让这些能力共同服务产品流程。