从JSON/YAML到AI Agent：用结构化数据构建人格化技能库的工程实践-编程阁

1. 项目概述：一个关于“初恋人格”的技能库

最近在GitHub上看到一个挺有意思的项目，叫first-love-persona-skill。光看名字，你可能会有点摸不着头脑——“初恋人格”和“技能”有什么关系？这难道是个恋爱模拟游戏的角色设定？或者是什么心理学测试工具？

其实都不是。这是一个典型的、由开发者个人兴趣驱动的“数字花园”类项目。它的核心，是尝试用结构化的数据（比如JSON、YAML）和可执行的代码（比如Python脚本），去定义、模拟甚至“计算”一种被称为“初恋人格”的复杂人类情感与行为模式。简单来说，就是开发者试图把他对“初恋”这种特定状态的理解，拆解成一个个可以描述、可以组合、甚至可以由程序来“触发”的“技能”。

这听起来有点抽象，甚至带点哲学或科幻色彩。但它的价值恰恰在于此：它站在了一个非常独特的交叉点上——一边是细腻的、非结构化的人类情感与社交直觉，另一边是严谨的、结构化的计算机逻辑与数据。做这个项目的人，大概率不是想开发一个商业产品，而是在进行一场有趣的思维实验和工程实践：我们能否用“开发者的语言”，去解构并重建那些我们以为只能“意会”的软技能？

这个项目适合谁来参考呢？首先是对“代码如何模拟人类行为”感兴趣的开发者，尤其是对AI Agent（智能体）、对话系统、角色扮演游戏（RPG）或叙事生成感兴趣的朋友。其次，是那些喜欢用项目管理或产品思维来梳理个人成长、人际关系等“软领域”的思考者。最后，它也适合任何想学习如何将一个模糊的、感性的概念，转化为清晰、可迭代的“项目”的实践者。接下来，我们就一起拆解这个项目背后的门道。

2. 项目核心思路与架构设计

2.1 “人格即技能集”的设计哲学

这个项目的底层逻辑非常清晰：它将一个人的“人格特质”或“在特定情境下的行为模式”，视为一系列“技能”的集合。这里的“技能”（Skill）是一个高度抽象的概念。它不仅仅指“会编程”、“会画画”这样的硬技能，更包括了“主动开启话题”、“察觉对方情绪变化”、“在尴尬时幽默化解”这类社交与情感层面的软技能。

为什么选择“初恋”这个场景？因为这是一个情感密度极高、行为模式既典型又充满个人差异的领域。它包含了紧张、期待、笨拙、真诚、过度思考等一系列鲜明特征。将这些特征模块化、技能化，比定义一个“通用友好人格”或“职场精英人格”更具挑战性，也更有趣。项目通过定义first-love-persona（初恋人格），实际上是在创建一个高度特化的“行为模型”。

在技术架构上，这类项目通常会采用“数据驱动”和“规则引擎”结合的方式。核心是一个技能定义文件（比如skills.json或persona.yaml），里面用键值对或更复杂的结构来描述每个技能。一个技能的定义可能包含：

技能ID与名称：如skill_001: initiate_conversation。
触发条件：在什么情境下这个技能可能被“激活”？例如，context: “silence_over_10_seconds”（沉默超过10秒）。
执行内容：技能具体做什么。这可能是一段预设的文本（action: “say: ‘你今天好像有点不一样？’”），一个调用外部API的指令，或一个概率选择（output: [“选项A”, “选项B”]）。
元数据：如技能的能量消耗（模拟心理负担）、冷却时间（避免重复使用）、与其他技能的关联性等。

2.2 技术栈选型与方案权衡

看到项目仓库（如changeworldBT/first-love-persona-skill），我们首先要推断其可能的技术实现。由于这是一个偏重逻辑与数据定义的项目，而非高性能计算或大型模型训练，其技术栈通常会追求轻量、灵活和可读性。

核心数据格式：JSON vs. YAML
- JSON是前端和Web API的绝对标准，结构严谨，解析速度快，几乎所有语言都原生支持。如果项目考虑未来与Web应用或JavaScript/Node.js生态深度集成，JSON是首选。它的缺点是缺乏注释，对于复杂嵌套结构，可读性稍差。
- YAML以其极高的可读性著称，支持注释，通过缩进表达层级，非常适合人类编写和阅读配置文件。如果技能定义非常复杂，包含大量说明性文字，YAML是更友好的选择。Python的PyYAML库解析起来也很方便。
- 选择建议：如果技能库是给“人”看和改的，优先YAML；如果主要是给“程序”读的，或者需要频繁通过网络传输，用JSON。从项目名称的“persona”（人格）来看，偏向人类可读的配置，YAML的可能性更大。
执行引擎：纯逻辑 vs. 集成AI
- 纯逻辑驱动：完全基于预设的规则和概率。例如，当检测到“对方分享了一个好消息”时，从[“表示祝贺”, “追问细节”, “分享类似经历”]这个技能池中，按预设权重随机选择一个执行。这种方式完全可控、可预测、无额外成本，适合构建确定性较强的互动原型。
- AI增强驱动：将技能作为“工具”或“提示词模板”提供给大型语言模型（LLM）。例如，技能定义变成：“当你需要赞美对方时，请参考以下格式：我发现你[对方的具体特质]，这让我觉得[你的感受]”。然后由LLM根据当前对话上下文，填充具体内容。这种方式灵活性极高，能生成更自然、更贴合的回应，但成本不可控，且输出结果有一定随机性。
- 选择建议：个人或实验性项目初期，从纯逻辑开始最能厘清核心设计。在技能框架稳定后，可以引入LLM作为“技能执行器”或“技能选择器”，实现从“规则智能”到“涌现智能”的过渡。项目仓库如果包含requirements.txt并有openai、langchain等库，则暗示了AI集成方向。

项目结构猜想一个典型的项目目录可能如下：

first-love-persona-skill/ ├── data/ │ ├── persona.yaml # 核心人格与技能定义 │ └── scenarios.json # 常见对话或互动场景定义 ├── engine/ │ ├── skill_loader.py # 加载和解析技能定义 │ ├── context_manager.py # 管理当前对话状态和上下文 │ └── executor.py # 根据上下文选择并执行技能 ├── examples/ │ └── demo_chat.py # 一个简单的命令行聊天演示 └── requirements.txt # 项目依赖

注意：以上技术栈和结构是基于常见实践的逻辑推演。实际项目中，开发者可能极简到只有一个skills.md文档，用自然语言描述技能树；也可能复杂到集成情感计算API。我们的分析重点在于理解这种“人格技能化”的设计范式，它本身比具体实现的技术选型更有普适价值。

3. 核心技能库的拆解与定义实践

3.1 如何定义一个“初恋场景技能”

我们以“发起对话”这个核心技能为例，看看如何从零开始定义一个技能。这不仅仅是写一段代码，更是对一种社交行为进行“需求分析”和“功能设计”。

首先，我们需要解构“发起对话”这个行为。在初恋的紧张语境下，它可能包含：

目标：打破沉默，建立连接，表达关注。
约束：不能太突兀，最好能自然衔接上文或当前环境；内容要得体，避免过度私人或令人不适。
变量：发起的时间（初次见面、日常聊天）、线上/线下、之前的对话历史。

基于此，我们可以设计一个技能的数据结构（以YAML为例）：

skills: - id: “break_ice_v1” name: “破冰者（环境观察型）” description: “通过评论双方所处的共享环境或当前活动，自然地开启对话，降低刻意感。” trigger_conditions: - condition_type: “conversation_state” value: “initial” # 对话初始状态 - condition_type: “shared_context” required: true # 必须存在共享环境（如都在咖啡馆、看到同一场雨） priority: 8 # 优先级，数值越高越优先被考虑 cooldown: 300 # 技能冷却时间（秒），防止短时间重复使用同类技能 action: type: “template_text” template: ““这个{{ context_item }}真不错，你也喜欢吗？” 或 “突然{{ weather_event }}了，你带伞了吗？”” variables: - name: “context_item” source: “environment” # 从环境上下文中提取，如“咖啡香气”、“背景音乐” - name: “weather_event” source: “external_api/weather” # 调用外部API获取天气信息 success_metrics: - metric: “response_delay” threshold: “<30s” # 期望对方在30秒内回应 - metric: “response_length” threshold: “>5 words” # 期望回应不是简单的“嗯”、“哦”

这个定义已经相当工程化了。它包含了技能的触发逻辑、执行内容、甚至还有简单的“成功指标”。在实际项目中，初期定义可能不会这么复杂，但“触发-执行-评估”这个核心循环是共通的。

3.2 构建技能间的关联与优先级网络

单一技能是孤立的，真实的人格体现在技能的选择与组合上。因此，我们需要建立技能之间的关系网络。这通常通过以下几种方式实现：

技能标签系统：为每个技能打上多个标签，如#破冰、#关心、#幽默、#深度话题、#高能耗。当处于“对方情绪低落”的上下文时，系统可以优先筛选带有#关心标签的技能，并避免使用#幽默标签（除非是#安慰式幽默）。
前置与后置技能：定义技能链。例如，skill_询问兴趣的成功执行，可能会高概率触发skill_推荐相关活动。这模拟了人类对话中话题的自然延伸。
状态影响：引入人格的“内部状态”变量，如能量值、紧张度、亲密感。不同技能会消耗或恢复这些状态。例如，一个精心准备的“深情告白”技能可能会消耗大量“能量值”并增加“紧张度”，导致后续一段时间内只能使用“低能耗”的简单回应技能。这让人格显得更有“生命感”和限制。
优先级动态调整：技能的优先级不是固定的。例如，如果一个#破冰技能连续两次未能获得良好回应（根据success_metrics判断），那么它的优先级可能在本次对话中临时降低，系统会更倾向于尝试其他类型的破冰技能。

在代码层面，这可能需要一个SkillManager类来维护所有技能实例、当前上下文、人格状态，并实现一个select_skill(context)方法。这个方法的核心是一个打分函数，为每个符合条件的技能计算一个“适宜度分数”，然后根据分数或概率抽样选择要执行的技能。

# 伪代码示例 class SkillManager: def select_skill(self, context): candidate_skills = [] for skill in self.all_skills: if skill.can_trigger(context): # 检查触发条件 score = self._calculate_score(skill, context) # 计算分数 candidate_skills.append((skill, score)) # 根据分数进行加权随机选择，避免总是选最高分显得机械 chosen_skill = weighted_random_select(candidate_skills) return chosen_skill def _calculate_score(self, skill, context): score = skill.base_priority # 基于标签匹配加分 for needed_tag in context.get(“needed_tags”, []): if needed_tag in skill.tags: score += 10 # 基于内部状态惩罚（如能量不足） if skill.energy_cost > self.persona_state.energy: score -= 50 # 基于冷却时间惩罚 if skill.is_in_cooldown(): score = 0 return score

4. 从定义到交互：实现一个简易对话引擎

4.1 上下文管理器的设计与实现

技能的执行离不开对“上下文”的理解。上下文管理器是这个系统的大脑，它负责收集、抽象并格式化当前交互的所有相关信息，供技能选择和执行使用。

一个基本的上下文对象可能包含以下维度：

对话历史：最近N轮对话的列表，包括谁说了什么。
人物状态：人格自身的状态（能量、情绪值）和对外部对象的认知状态（如“已知对方喜欢咖啡”）。
环境信息：时间、地点（如果是模拟）、可能的共享事件（如“正在听同一首歌”）。
交互元信息：本次消息的发送渠道（微信、线下）、延迟时间、是否包含多媒体等。

上下文管理器的核心任务，是将这些原始数据转化为技能可以理解的“特征”或“标签”。例如，当对话历史连续出现三次由对方结尾的短句（如“嗯”、“好的”、“哈哈”），上下文管理器可以生成一个conversation_momentum: low（对话动量低）的特征。当识别到对方消息中包含“累”、“困”等关键词时，可以生成一个needed_tags: [“关心”, “结束对话”]的需求标签。

# 上下文管理器的简化示例 class ContextManager: def __init__(self): self.dialog_history = [] self.persona_state = {“energy”: 100, “closeness”: 0} self.environment = {} self.derived_features = {} def update(self, new_message, sender, env_info=None): """更新上下文""" self.dialog_history.append({“sender”: sender, “text”: new_message}) # 保留最近10轮历史 if len(self.dialog_history) > 10: self.dialog_history.pop(0) self.environment.update(env_info or {}) self._analyze_features() def _analyze_features(self): """分析历史，生成衍生特征""" self.derived_features.clear() # 分析对话动量 recent_responses = [msg for msg in self.dialog_history[-3:] if msg[“sender”] == “other”] if len(recent_responses) >= 2 and all(len(msg[“text”]) < 5 for msg in recent_responses): self.derived_features[“conversation_momentum”] = “low” # 分析情绪关键词（非常简单的示例） last_msg = self.dialog_history[-1][“text”] if self.dialog_history else “” negative_words = [“累”, “烦”, “难过”] if any(word in last_msg for word in negative_words): self.derived_features[“needed_tags”] = [“关心”, “倾听”]

4.2 技能执行与反馈循环的闭环

当技能被选中后，执行器负责将其“动作”转化为实际的输出。对于文本对话，这可能就是拼接字符串；对于更复杂的动作，可能需要调用外部服务。

执行后的反馈至关重要，它用于更新人格状态和评估技能效果，形成学习闭环。这个反馈可以来自预设规则，也可以来自一个简单的“用户满意度”模拟（在无真实用户的情况下）。

class SkillExecutor: def execute(self, skill, context): """执行技能""" if skill.action[“type”] == “template_text”: output = self._render_template(skill.action[“template”], context) # 模拟执行消耗 context.persona_state[“energy”] -= skill.energy_cost skill.last_used_time = time.time() # 记录使用时间，用于冷却 return output # ... 处理其他类型的action def receive_feedback(self, skill, context, response): """接收对技能执行的反馈，并更新技能权重或人格状态""" # 简单的反馈规则：如果对方回应长且积极，则增强相关标签的权重 response_len = len(response) if response_len > 20 and self._contains_positive_words(response): # 增强本次使用技能的所有标签的关联权重 for tag in skill.tags: self.skill_manager.tag_weights[tag] *= 1.1 # 恢复少许能量 context.persona_state[“energy”] = min(100, context.persona_state[“energy”] + 10)

通过这个“感知（上下文管理）-决策（技能选择）-执行-反馈”的循环，一个静态定义的技能库就开始动态运转起来，呈现出一种初级的、基于规则的行为智能。

5. 项目深化：从规则到学习的可能路径

5.1 引入概率模型与不确定性

纯规则系统的一个明显缺点是过于机械和可预测。要让人格显得更“自然”，必须引入不确定性。这可以在多个层面实现：

技能选择概率化：不要总是选择分数最高的技能。可以使用Softmax函数将分数转化为概率分布，然后依概率随机选择。这样，即使在同一上下文中，也可能产生不同的行为输出。
技能输出多样化：一个技能可以对应多个输出模板，并为其设置不同的权重。例如，“打招呼”技能可以有[“嗨！”, “你好呀~”, “（微笑表情）下午好”]三个选项，权重分别为[0.5, 0.3, 0.2]。
参数模糊化：技能定义中的一些数值，如冷却时间、能量消耗，可以不是一个固定值，而是一个范围（如cooldown: “180-600”），每次使用时随机选取。触发条件也可以加入概率因子（如trigger_probability: 0.7）。

这些不确定性使得系统的行为难以被完全预测，更贴近人类行为的随机性和灵活性。

5.2 集成大语言模型作为高级处理器

当技能框架搭建稳固后，集成大语言模型（LLM）可以将项目的表现力提升数个量级。这里有两种主要的集成模式：

LLM作为技能选择器：将当前丰富的上下文（对话历史、人格状态、环境特征）格式化后，连同所有可用技能的描述，一起提交给LLM。提示词（Prompt）可以是：“你是一个拥有以下技能的人格：[技能列表]。当前情况是：[上下文]。请从技能列表中选择一个最合适现在使用的技能，并说明理由。” 然后解析LLM的输出，执行它选择的技能。这相当于让LLM来做复杂的上下文理解和策略判断。
LLM作为技能内容生成器：技能的定义不再是一个固定的文本模板，而是一个给LLM的“指令模板”。例如，一个“表达关心”的技能，其动作可能是调用LLM API，并附上提示词：“请用真诚、简洁的语气，对以下对话中表达疲惫的人说一句关心的话。对话历史：[历史]。要求：不超过20字。” 这样，每次执行这个技能，都能生成贴合具体情境的、不重样的关心话语。

这种模式下，本地定义的技能库更像是一个“工具箱”和“行为规范手册”，而LLM则是灵活运用这些工具的“大脑”。项目重心就从“编写具体行为”转移到了“设计有效的提示词和管控流程”上。

5.3 长期记忆与人格演进

一个更有野心的方向是为人格引入长期记忆，并让其行为基于记忆产生演进。这可以通过以下方式实现：

事实记忆：记录在互动中获取的关于对方的关键信息（“喜欢科幻电影”、“对芒果过敏”）。这些信息会成为未来上下文的一部分，影响技能选择。例如，当上下文中有“电影”相关话题且记忆库中存在“对方喜欢科幻”时，一个“推荐电影”技能的优先级会大幅提高。
互动记忆：记录重要的共同经历或对话片段（“第一次长谈至深夜”、“曾因某话题产生小误会”）。在周年或相关话题触发时，可以激活“回忆杀”类技能。
人格参数微调：基于长期的互动反馈，动态调整人格的底层参数。例如，如果“主动开玩笑”技能多次导致对话冷场，系统可以自动降低“幽默倾向”这个内部参数，并提高“共情倾向”参数。这模拟了人格通过经验进行微调的过程。

实现长期记忆需要设计一个向量数据库（如ChromaDB, Faiss）来存储和检索记忆片段，并将相关的记忆在需要时注入到LLM的上下文或本地技能选择器的判断依据中。

6. 实践中的挑战、心得与避坑指南

6.1 从“过拟合”到“泛化”的平衡

在定义“初恋人格”技能时，最容易陷入的陷阱就是“过拟合”——即把技能定义得过于具体、过于场景化，以至于离开你设想的那个特定对话流程，它就完全失灵。比如，你定义了一个技能：“如果对方说‘我刚看完《星际穿越》’，就回复‘我也爱看！诺兰的电影总是让人思考时间与爱’。” 这个技能在遇到这句话时完美工作，但对方如果说的是“我刚看完《沙丘》”，这个技能就无效了。

避坑策略：定义技能时，要追求更高层次的抽象。与其定义“针对《星际穿越》的回应”，不如定义“针对‘分享刚完成的文化消费（电影/书/音乐）’的回应”。技能的触发条件应该是一类情境，而不是一个具体实例。执行内容也应该是一个可填充的模板，而不是固定文本。例如，模板可以是：“听起来很棒！我也对[作品类型]感兴趣，特别是[从对方描述或已知喜好中提取的相关点]。” 这样，技能的泛化能力就强得多。

6.2 技能冲突与状态管理的复杂性

当技能数量增多后，技能之间的冲突和状态管理会变得非常棘手。例如，“想分享一个有趣的故事”和“察觉到对方需要倾诉”这两个技能可能在同一时刻都被触发。如何仲裁？再比如，人格的“能量值”系统，如果设计不当，很容易导致人格在互动初期就“耗竭”，或者永远处于“满能量”的失真状态。

实操心得：

引入清晰的技能分类和互斥组：将技能分为“破冰”、“深入交流”、“关心”、“幽默”、“结束对话”等大类。同一时刻，可能只允许从“深入交流”和“关心”中选择一个优先级最高的执行。可以设置互斥组（Mutual Exclusive Group），同组技能不能同时被选中。
状态设计要贴合心理现实：“能量值”的消耗和恢复速率需要精心调参。可以设计不同层次的恢复机制：每次成功互动恢复少量，静默一段时间恢复中量，经过一个“睡眠周期”（在模拟中）恢复大量。这样更符合人的社交精力变化。
使用配置文件管理参数：将所有可调参数（优先级基数、消耗值、冷却时间、状态恢复速率）放在一个单独的配置文件中（如config.yaml）。这样，你可以通过调整配置文件来快速平衡整个系统的行为，而无需修改核心代码。

6.3 评估体系的建立：何为“好”的互动？

对于这样一个项目，最难的问题之一是如何评估其效果。没有明确的“正确输出”。你可以通过自动化测试来验证技能触发逻辑是否正确，但人格的“得体性”、“趣味性”如何衡量？

我的经验是采用分层评估法：

单元测试（技能层面）：测试每个技能在给定上下文输入下，是否能正确触发并生成符合语法的输出。
集成测试（对话流层面）：设计一系列标准的对话场景（如“初次打招呼”、“安慰失落的朋友”、“讨论一个分歧”），让人格与一个简单的脚本机器人进行多轮对话。评估者（可以是开发者自己或邀请的朋友）根据对话的流畅度、得体性、趣味性进行主观打分（1-5分）。
A/B测试（策略层面）：如果你对某个技能或参数进行了修改，可以运行新旧两个版本的人格，在相同的多个对话场景下进行交互，对比它们的输出，看哪个更受欢迎。
关键指标监控：定义一些可量化的、间接的“健康指标”，如：
- 对话长度：平均对话轮次是否增加？（可能意味着互动更吸引人）
- 技能多样性：在长对话中，使用了多少种不同的技能？（避免重复单调）
- 负面反馈规避：当模拟用户发出“结束对话”、“无聊”等信号时，人格是否能及时察觉并调整？

最终，评估的核心可能还是人的主观感受。这个项目更像一个数字艺术品或一个思维玩具，其价值在于构建过程中对人性、社交和智能的思考，以及那一点点让造物“活”起来的惊喜感。