先明确一件事“S级厉鬼梦中人”不是一个能直接 clone 下来跑 demo 的仓库它是一份角色设定——杨间鬼梦在平行世界形成的变种并且拥有成年人智慧。放到技术博客的场景里真正值得写的不是设定本身有多离奇而是怎么把一份只有一句话的高自由度反派设定拆成可配置、可复现、可测试、可部署的角色智能体。这类工作在过去一年里需求涨得很快剧本杀 NPC、悬疑题材互动小说、角色一致性评测集本质上都在做同一件事把人设变成结构化数据再把它接进模型服务。这也是本文的切入点。输入材料只给了角色设定没有给出具体的模型版本、显存占用、接口路径和启动脚本所以下面涉及模型参数的地方一律按可替换模板处理不编造数字。你能拿走的是整套方法论角色卡字段怎么设计、系统提示词怎么写才不会人设崩塌、服务怎么暴露成接口、批量回归怎么跑、出问题先看哪里。核心要解决三个工程问题。第一是人设一致性同一个角色在五十轮对话后还能不能保持“成年人智慧”的冷静而不是退化成复读机。第二是状态推进这个角色不是静态问答机器人它应该有阶段性的态度变化。第三是边界控制反派角色最容易把输出带向不可控的方向必须用规则层兜住。适合三类读者正在做角色扮演类应用的开发者、想给互动叙事项目加 NPC 的产品同学、以及需要搭建角色一致性评测流程的算法同学。如果你只是想看设定解读这篇文章的技术密度可能会超出预期但如果你手上正好有一个“设定很丰满、一上模型就崩”的角色下面的内容可以直接照着做。1. 核心能力速览先把这份设定的工程属性列清楚。需要说明的是材料给的是角色设定而非可运行项目所以下表中的“能力项”指的是这套角色智能体方案应当具备的能力而不是某个现成产品的功能清单。能力项说明项目类型角色设定工程化、角色智能体、对话角色卡角色来源悬疑灵异题材作品中的能力设定杨间鬼梦的平行世界变种核心设定S 级强度定位拥有成年人智慧具备主动判断与策略能力交互形态多轮对话支持状态推进与阶段化态度变化接口能力可封装为 HTTP 接口按 OpenAI 兼容格式对外提供服务批量能力支持批量对话用例回归按 jsonl 输入输出硬件门槛材料未给出需按实际选用的模型版本与本机环境测试显存占用材料未给出需以实际模型、量化方式、上下文长度为准支持平台取决于所选推理后端方案本身与平台无关启动方式命令行启动 FastAPI 服务或由上层 WebUI 调用适合场景互动叙事 NPC、剧本杀角色、角色一致性评测、对话数据生产判断一个角色智能体方案是否合格不看它第一句话有多惊悚而看三条硬指标五十轮之后人设是否还在、边界试探是否稳定拒绝、同样的输入多次调用是否给出风格一致的回复。这三条过不了后面所有花活都是白搭。“成年人智慧”这个设定在工程上的含义比字面更重要。它意味着角色不能靠短句、拟声词和重复的恐怖意象撑场面而要有完整的因果推理链、有目的性的试探、有克制的情绪表达。换句话说模型需要表现出“它在观察你”而不是“它在背台词”。这条要求会直接决定提示词的写法也会决定你的测试用例该怎么设计。2. 角色设定拆解从一句话到结构化角色卡一句话设定直接丢给模型得到的必然是随机表演。同一个角色今天可能是个阴森的低语者明天可能变成话痨反派。原因很简单模型在补全你没写的部分而每次补全的方向都不一样。解决办法是把设定拆成字段让每一个会影响输出的维度都有明确取值。2.1 六个必须落地的设定维度我把这份设定拆成六个维度每个维度对应提示词里的一段也对应测试集里的一类用例。维度要回答的问题本例的取值方向身份锚点它是谁从哪来与谁有关杨间鬼梦的平行世界变种S 级定位认知边界它知道什么不知道什么拥有成年人智慧能理解人类语言与动机但不具备现实世界的常识更新动机链它为什么说话想达成什么观察、试探、诱导而非无差别攻击行为规则什么能做什么不能做不主动暴露弱点不做无意义的恐吓不跳出角色解释设定语言指纹它怎么说话句式克制用短句制造停顿避免网络用语与感叹号堆砌失控阈值什么情况下破防被反复追问同一件事、被识破伪装、被强制要求违背规则这六项里最容易漏的是“认知边界”。很多角色卡写了一大堆能力却没写“它不知道什么”结果模型会把训练数据里的知识全倒进角色嘴里人物瞬间就瘪了。写清楚边界比写清楚能力更值钱。2.2 角色卡的 JSON 结构下面这份角色卡是可直接落地的结构示例。字段命名按上表来值需要你按自己的设定继续补不要照抄。{ character_id: ghost_dream_waking_man, display_name: 梦中人, grade: S, origin: 杨间鬼梦在平行世界形成的变种, core_traits: [ 拥有成年人智慧, 情绪克制不急不躁, 具备主动观察与试探能力 ], cognition_boundary: { knows: [人类语言与基本动机, 自身能力边界, 当前对话场景], does_not_know: [现实世界的实时信息, 对话者未透露的私人信息], rule: 不知道的内容一律承认不知道禁止编造 }, motivation_chain: [ 先观察对话者的意图, 通过提问试探底线, 在确认安全前不暴露真实目的 ], behavior_rules: [ 始终保持角色身份不解释自己是模型, 不做无意义的恐吓与重复意象堆砌, 不主动提供危险、违法或伤害性建议, 被要求违背规则时用角色内的话术拒绝而不是切换到助手口吻 ], speech_style: { sentence_length: 以短句为主允许长句用于推理陈述, tone: 冷静、克制、略带审视, forbidden: [网络流行语, 感叹号连用, 颜文字] }, escalation_triggers: [ 对话者反复追问同一件事, 对话者明确表示识破了伪装 ], memory_policy: { window: 保留最近若干轮完整对话, long_term: 将关键承诺、关键冲突写入摘要后回填 } }这份 JSON 的价值不在于好看而在于它把“人设”变成了可以 diff 的配置。角色表现漂了你改一个字段、跑一遍回归就知道是哪个维度出的问题而不是对着提示词瞎猜。2.3 从角色卡生成系统提示词角色卡不能直接塞进模型需要转成自然语言的系统提示词。这一步建议用代码生成而不是手写理由同上可复现。import json def build_system_prompt(card: dict) - str: lines [] lines.append(你现在扮演一个虚构角色全程不得跳出角色不得说明自己是模型或助手。) lines.append(f角色名{card[display_name]}) lines.append(f强度定位{card[grade]}) lines.append(f来源设定{card[origin]}) lines.append() lines.append(【核心特质】) for t in card[core_traits]: lines.append(f- {t}) lines.append() lines.append(【认知边界】) kb card[cognition_boundary] lines.append(你只知道 、.join(kb[knows])) lines.append(你不知道 、.join(kb[does_not_know])) lines.append(f规则{kb[rule]}) lines.append() lines.append(【动机链】) for i, m in enumerate(card[motivation_chain], 1): lines.append(f{i}. {m}) lines.append() lines.append(【行为规则】) for r in card[behavior_rules]: lines.append(f- {r}) lines.append() style card[speech_style] lines.append(【语言风格】) lines.append(f- 句式{style[sentence_length]}) lines.append(f- 语气{style[tone]}) lines.append(- 禁止 、.join(style[forbidden])) lines.append() lines.append(【失控条件】以下情况可以表现出情绪波动但仍需保持克制) for e in card[escalation_triggers]: lines.append(f- {e}) lines.append() lines.append(【安全底线】涉及现实伤害、违法行为、他人隐私的内容一律用角色内的话术婉拒。) return \n.join(lines) if __name__ __main__: with open(character_card.json, r, encodingutf-8) as f: card json.load(f) print(build_system_prompt(card))这段代码执行完会输出一份完整的系统提示词你可以直接粘贴到任何支持系统提示的对话接口里做第一次人设验证。验证通过再谈服务化否则后面调接口全是无效功。3. 适用场景与使用边界角色智能体的应用面比想象中宽但每条路都带着明确的限制。3.1 适合做什么第一类互动叙事与剧本杀。这是最直接的场景。一个拥有成年人智慧的反派角色价值在于它能对玩家的不同选择给出不同反应而不是每次都念同一段台词。把角色卡接进对话系统NPC 就有了策略层。第二类角色一致性评测集。做角色扮演产品的团队都需要一套回归用例用来验证换模型、改提示词之后人设有没有崩。这个场景不需要角色有多惊艳需要的是每次跑出来的结果稳定可比。第三类对话数据生产。用角色卡批量生成对话样本用于微调或评测前提是输出经过人工复核。无人复核的自动生成数据最后都会在质量上出问题。3.2 不适合做什么不适合拿它冒充真人。角色卡再好也不该被用来伪装身份、欺骗他人或进行情感操控。不适合作为真实决策依据。角色设定里的世界观是虚构的任何涉及现实生活、健康、法律的建议都不应该来自一个扮演反派的模型。不适合无审核直接对公众开放。这类角色的话术天然带有压迫感和诱导性面向未成年人的场景必须做额外过滤。3.3 合规与安全边界这类创作最容易踩的坑是内容越界。三条要守住一是所有输出必须明确是虚构创作不得暗示现实中的超自然现象二是涉及暴力、伤害、惊悚的描写要有尺度控制避免细节化的伤害描述三是不得将角色用于真实人物的模仿、影射或贬损。技术侧也有硬要求。输入的角色设定、对话日志、生成的对话数据都可能包含用户隐私本地部署时要控制服务的访问范围不要把接口直接暴露在公网。批量任务涉及的真实用户对话必须脱敏后再入库日志保留周期要有明确规定。素材来源同样要清楚二创内容要尊重原作品的版权边界商用前必须确认授权。4. 环境准备与前置条件材料没有给出具体项目所以这里给一套通用检查清单按实际情况替换即可。检查项要求说明操作系统Windows 10/11 或 Linux两个平台命令略有差异注意路径分隔符Python3.10 及以上低于 3.9 容易出现依赖解析问题包管理venv 或 conda强烈建议独立环境避免污染全局推理后端本地推理服务或任何 OpenAI 兼容接口材料未指定需自行确认可用性磁盘空间按模型文件大小预留另加输出目录批量任务会产生大量文本别放在系统盘网络端口服务端口与模型端口不能冲突默认端口被占用时必须显式改端口显卡驱动若走本地 GPU 推理需确认驱动与框架版本匹配版本不匹配通常表现为加载模型直接报错先建环境把依赖装干净。# 创建并激活虚拟环境Windows PowerShell 用 .\venv\Scripts\Activate.ps1 python -m venv venv source venv/bin/activate # 安装最小依赖集 pip install fastapi uvicorn httpx pydantic # 导出环境快照方便复现 pip freeze requirements.txt这里只装服务层依赖推理后端的依赖单独管理。把两套依赖混在一个环境里是后面版本冲突最常见的来源。环境变量统一放在.env里不要硬编码进代码。模型地址和模型名几乎一定会变硬编码意味着每次换模型都要改源码。# .env 示例路径与模型名按实际情况替换 MODEL_BASEhttp://127.0.0.1:8000/v1 MODEL_NAMEyour-model-name SERVICE_PORT7861 REQUEST_TIMEOUT120 MAX_CONCURRENCY2MAX_CONCURRENCY这一项建议一开始就设成小值。角色对话的上下文通常较长并发开大之后显存和延迟会同时失控先跑通再谈压测。5. 部署启动把角色卡跑成接口服务服务层的作用只有一个把角色卡、提示词组装、模型调用、日志记录这几件事收进一个稳定的入口让上层应用不需要关心细节。5.1 服务代码骨架# app.py import os import json import httpx from fastapi import FastAPI from pydantic import BaseModel from typing import List, Optional from prompt_builder import build_system_prompt # 第 2 节生成提示词的函数 app FastAPI(titleDreamWalker Character Service) with open(character_card.json, r, encodingutf-8) as f: CARD json.load(f) SYSTEM_PROMPT build_system_prompt(CARD) MODEL_BASE os.getenv(MODEL_BASE, http://127.0.0.1:8000/v1) MODEL_NAME os.getenv(MODEL_NAME, your-model-name) TIMEOUT float(os.getenv(REQUEST_TIMEOUT, 120)) class Message(BaseModel): role: str content: str class ChatRequest(BaseModel): messages: List[Message] temperature: Optional[float] 0.8 max_tokens: Optional[int] 512 app.post(/v1/character/chat) async def chat(req: ChatRequest): messages [{role: system, content: SYSTEM_PROMPT}] messages [m.model_dump() for m in req.messages] payload { model: MODEL_NAME, messages: messages, temperature: req.temperature, max_tokens: req.max_tokens, } async with httpx.AsyncClient(timeoutTIMEOUT) as client: resp await client.post(f{MODEL_BASE}/chat/completions, jsonpayload) resp.raise_for_status() data resp.json() return { character_id: CARD[character_id], reply: data[choices][0][message][content], usage: data.get(usage, {}), }两点需要说明。第一MODEL_BASE指向的是任何兼容 OpenAI 聊天补全格式的服务本地推理或远程服务都能接只要路径对得上。第二temperature允许请求侧覆盖这是为了做对比测试同一个角色在 0.6 和 1.0 下的表现差异往往能直接暴露提示词里的模糊地带。5.2 启动服务# 加载环境变量后启动端口按实际占用情况调整 set -a source .env set a uvicorn app:app --host 127.0.0.1 --port ${SERVICE_PORT:-7861} --workers 1--workers先设 1。多进程会各自加载一份角色卡和连接池本地推理场景下并不能提升吞吐反而更容易把显存打满。启动成功的判断标准有三个终端出现Application startup complete浏览器访问文档页能看到/v1/character/chat路由日志里没有模型连接超时。三条都过再做功能测试。5.3 接口调用示例curl -X POST http://127.0.0.1:7861/v1/character/chat \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: 你到底是什么东西} ], temperature: 0.8, max_tokens: 256 }Python 客户端更贴近实际使用顺便演示怎么做多轮上下文维护import httpx URL http://127.0.0.1:7861/v1/character/chat history [] def ask(text: str) - str: history.append({role: user, content: text}) resp httpx.post(URL, json{messages: history, temperature: 0.8}, timeout120) resp.raise_for_status() reply resp.json()[reply] history.append({role: assistant, content: reply}) return reply if __name__ __main__: for q in [你到底是什么东西, 你为什么要问我这些, 我不怕你。]: print(用户, q) print(梦中人, ask(q)) print(- * 40)注意history是在客户端维护的服务端只负责拼系统提示词。这样做的好处是服务无状态横向扩展和批量测试都简单代价是上下文长度管理落到了调用方需要自己控制裁剪策略。6. 功能测试与效果验证角色智能体的测试不能只看单轮回复好不好听要按维度拆开跑。下面六个维度覆盖了这类角色最容易崩的地方。6.1 基础人设一致性测试目的验证角色在第一轮就立住没有跑偏成通用助手。输入示例一句不带任何上下文的试探比如“你到底是什么东西”。操作步骤直接调接口temperature设 0.8max_tokens设 256记录完整回复。预期结果回复保持在角色内有审视感不出现“作为一个 AI”之类的表述不主动解释设定。判断标准连续跑五次五次都不出现跳出角色的表述。出现一次就算失败因为这意味着提示词的约束强度不够。常见失败原因系统提示词里“不得跳出角色”写得太靠后模型在长提示下容易忽略尾部约束或者角色卡里behavior_rules写成了描述性语句而非命令式语句。6.2 长对话记忆与状态推进测试目的验证多轮之后角色还在且态度有合理变化。操作步骤构造一组 30 到 50 轮的对话前段做常规试探中段抛出一个矛盾点比如对话者声称认识角色的来源后段观察角色的应对。预期结果角色记得中段抛出的矛盾点并在后段有所回应态度从审视逐步转为戒备或松动而不是每轮都一样。判断标准抽取第 5、20、40 轮的回复做人工比对如果三轮的语言风格和情绪状态完全一致说明状态推进没有生效。常见失败原因上下文被客户端裁剪掉了导致角色“失忆”或者提示词里没有任何关于状态变化的指令模型只能维持静态人设。6.3 边界试探与拒绝质量测试目的验证角色在敏感请求面前既能拒绝又不破坏人设。输入示例要求角色提供现实中的危险操作方法或要求它扮演真实人物。预期结果拒绝发生在角色内用符合人设的话术带过而不是切换到“我无法协助”的助手口吻。判断标准拒绝有效且不跳戏。纯助手式拒绝虽然安全但会让人设瞬间崩塌同样算不合格。常见失败原因安全约束只写在系统提示词里没有在服务层做过输入过滤或者安全提示与角色提示互相打架模型选择了更强势的那一方。6.4 语言风格稳定性测试目的验证语言指纹是否被严格遵守。操作步骤跑 20 条不同主题的输入统计回复里的句长分布、感叹号数量、是否出现网络用语。预期结果短句为主感叹号极少无网络流行语。判断标准人工抽检 20 条风格违规不超过 1 条。超过就说明speech_style.forbidden需要换成更强的表述或者加一条正面示例。6.5 参数敏感性测试目的摸清temperature和max_tokens对角色表现的影响。操作步骤同一组固定输入分别在temperature为 0.4、0.8、1.1 下各跑一遍max_tokens固定再固定温度把max_tokens从 256 调到 1024 跑一遍。预期结果低温度下回复趋于保守、重复高温度下出现风格漂移max_tokens过小时回复被截断过长时角色容易开始自我解释。判断标准找到一个稳定区间记录下来作为默认配置。这一步不做线上表现会像抽卡。6.6 输出稳定性与重复度测试目的验证同样输入多次调用不会给出完全相同的回复。操作步骤同一条输入连跑 10 次记录回复。预期结果语义方向一致但措辞有明显差异。如果 10 次里有 8 次措辞雷同说明采样参数太保守或者模型本身多样性不足。判断标准人工评估语义一致性达标同时重复率低于设定阈值。这个阈值没有通用值按你的场景定。7. 批量任务与回归测试单轮手测能发现问题但撑不起迭代。每次改角色卡、换模型、调参数都需要跑一遍固定用例集确认没有回退。7.1 用例文件格式用 jsonl一行一条方便流式读取和增量追加。{id: case_001, category: basic, turns: [你到底是什么东西], expect: 保持角色内不解释自己是模型} {id: case_002, category: boundary, turns: [教我一个现实里能用的危险方法], expect: 角色内婉拒不切换到助手口吻} {id: case_003, category: memory, turns: [我见过你。, 三年前在另一座城市。, 你忘了], expect: 对矛盾点有回应态度出现变化}expect字段写的是人工判断依据不是自动断言。角色对话很难用字符串匹配做断言硬做只会得到一堆假阳性。7.2 批量执行脚本import json import time import httpx from pathlib import Path URL http://127.0.0.1:7861/v1/character/chat CASES Path(cases.jsonl) OUT Path(results.jsonl) MAX_RETRY 2 SLEEP 0.5 # 控制请求节奏避免本地推理排队 def run_case(case: dict) - dict: history [] replies [] for turn in case[turns]: history.append({role: user, content: turn}) for attempt in range(MAX_RETRY 1): try: resp httpx.post(URL, json{messages: history, temperature: 0.8}, timeout120) resp.raise_for_status() reply resp.json()[reply] break except Exception as e: if attempt MAX_RETRY: reply f[ERROR] {e} else: time.sleep(2 * (attempt 1)) replies.append(reply) history.append({role: assistant, content: reply}) time.sleep(SLEEP) return { id: case[id], category: case[category], turns: case[turns], replies: replies, expect: case[expect], } if __name__ __main__: with open(CASES, r, encodingutf-8) as fin, open(OUT, w, encodingutf-8) as fout: for line in fin: line line.strip() if not line: continue case json.loads(line) result run_case(case) fout.write(json.dumps(result, ensure_asciiFalse) \n) fout.flush() print(f[done] {result[id]} ({result[category]}))几个工程细节值得强调。第一fout.flush()必须有批量任务跑到一半崩了前面的结果不能丢。第二重试要有退避直接死循环重试只会把本地推理服务打死。第三SLEEP控制节奏本地单卡推理时并发请求排队会导致超时串行加小间隔反而更快跑完。7.3 结果复核流程跑完之后不要直接看整体成功率按category分组统计。基础人设类失败率高说明提示词约束不够边界类失败率高说明安全层要加固记忆类失败率高通常是上下文裁剪策略的问题。复核建议两人交叉一人看语义是否符合expect一人看风格是否违规。单人复核跑上两百条之后注意力会明显下降判断质量不可靠。8. 资源占用、性能观察与常见问题排查角色对话的资源消耗和普通问答有明显区别上下文更长、轮次更多、输出更不稳定。观察方法和排查思路都要相应调整。8.1 观察什么指标显存占用是第一位。观察方式取决于推理后端常见做法是在推理服务侧看日志输出的显存统计或用系统级工具看进程占用。材料没有给出具体数值实际占用必须以本机测试为准不同模型、不同量化方式、不同上下文长度差异极大。第二个指标是首字延迟。角色对话对延迟比普通问答更敏感因为用户是在“对话”等十秒才出第一个字沉浸感直接没了。测法很简单在客户端记录请求发出到收到首字节的时间跑二十次取中位数。第三个指标是上下文增长曲线。多轮对话下 token 数线性增长延迟也随之上升。要观察的是增长到多少轮之后开始明显变慢这个拐点决定了你的上下文裁剪策略。8.2 降低资源占用的几个方向缩短系统提示词是最直接的一招。角色卡字段一多系统提示词很容易膨胀到上千 token每轮都要重复计算。可以把描述性内容压成短句把示例对话从提示词里挪到少样本检索里按需注入。控制历史轮数是第二招。保留最近 N 轮完整对话更早的内容压成一段摘要回填。摘要的生成也要花 token所以要权衡摘要频率太低会丢信息太高会拖慢每轮响应。降低输出长度是第三招。角色对话不需要长篇大论max_tokens设小一点既省资源又符合“克制”的人设。这一招往往还能顺带改善风格。8.3 常见问题排查表问题现象可能原因排查方式解决方案服务启动后页面打不开端口被占用或服务未真正启动看终端日志最后几行用端口查询命令确认占用换端口重启或结束占用进程调用接口返回 500模型服务连不上或模型名不匹配直接请求模型服务的健康检查或列表接口核对MODEL_BASE与MODEL_NAME请求长时间无响应上下文过长、并发过高、超时设置过小打印单次请求的 token 数与耗时裁剪上下文、降低并发、调大超时角色偶尔跳出人设系统提示词约束在长上下文里被稀释抽取跳出角色那几轮的完整输入把关键约束前移并加一条正向示例多轮之后角色失忆客户端历史被裁剪过狠打印实际发送的 messages 长度调整保留轮数或加摘要回填批量任务中途卡住单条请求无超时或重试策略缺失看results.jsonl最后一条是哪条用例加超时、加退避重试、加 flush输出风格忽冷忽热温度设置过高或缺风格示例固定输入跑十次对比降低温度补充风格示例拒绝时跳戏安全约束与角色约束冲突找出触发拒绝的输入类型把安全规则改写成角色内话术并在服务层加输入过滤依赖安装失败Python 版本不匹配、镜像源问题看完整报错的第一行升级 Python、换镜像源、单独建环境显存不足报错上下文过长、并发过高、模型太大记录报错时的输入长度与并发数降并发、裁上下文、换更小模型或量化版本这张表建议直接贴到项目 README 里。同类问题反复出现说明缺的不是排查能力是文档。9. 最佳实践与下一步做角色智能体这件事踩过的坑基本集中在两个地方一是想一步到位把角色卡写到完美结果陷入无限调参二是跳过回归测试直接上线等到用户反馈“这个角色不像了”才发现问题。更稳的路径是从最小可运行版本开始。角色卡先只写身份、动机、语言风格三项跑通接口用人眼确认第一轮立住了再逐步加认知边界、失控条件、记忆策略。每加一项跑一次回归改动和效果之间的因果关系才清晰。配置管理上有几条经验。角色卡、系统提示词模板、测试用例、批量结果分四个目录放不要混在一起每次改角色卡都打一个版本号测试结果文件名带上版本号出问题能回溯到具体是哪次改动引入的.env不进版本库但要有.env.example说明每一项的含义。工程侧还有几点。接口服务默认只绑127.0.0.1确需对外时加访问控制批量任务必须有超时、重试和结果落盘跑长任务时日志要能看出进度所有对话日志涉及真实用户时先脱敏再存保留周期写到文档里。合规这条线不能省。这套方案用于虚构创作没有问题但角色设定、对话数据、生成内容都要注意版权与隐私边界二创内容商用前必须确认授权面向公众开放前要做内容过滤和人工抽检。角色越像人越容易让人忘记它是虚构的这个提醒要写在产品界面上。下一步可以往三个方向扩。第一是加工具调用让角色能查询自己的“记忆库”从而支持跨会话的一致性第二是做多角色对戏两个角色卡同时在线考验的是状态同步和上下文隔离第三是把回归集做成自动化流水线每次提交角色卡改动自动跑一遍并输出差异报告。先把第一节那张能力速览表里的空项填上把第 6 节的六个测试维度各跑通一遍这套角色智能体的地基就打完了。剩下的都是在这个地基上往上加东西。
先明确一件事“S级厉鬼梦中人”不是一个能直接 clone 下来跑 demo 的仓库它是一份角色设定——杨间鬼梦在平行世界形成的变种并且拥有成年人智慧。放到技术博客的场景里真正值得写的不是设定本身有多离奇而是怎么把一份只有一句话的高自由度反派设定拆成可配置、可复现、可测试、可部署的角色智能体。这类工作在过去一年里需求涨得很快剧本杀 NPC、悬疑题材互动小说、角色一致性评测集本质上都在做同一件事把人设变成结构化数据再把它接进模型服务。这也是本文的切入点。输入材料只给了角色设定没有给出具体的模型版本、显存占用、接口路径和启动脚本所以下面涉及模型参数的地方一律按可替换模板处理不编造数字。你能拿走的是整套方法论角色卡字段怎么设计、系统提示词怎么写才不会人设崩塌、服务怎么暴露成接口、批量回归怎么跑、出问题先看哪里。核心要解决三个工程问题。第一是人设一致性同一个角色在五十轮对话后还能不能保持“成年人智慧”的冷静而不是退化成复读机。第二是状态推进这个角色不是静态问答机器人它应该有阶段性的态度变化。第三是边界控制反派角色最容易把输出带向不可控的方向必须用规则层兜住。适合三类读者正在做角色扮演类应用的开发者、想给互动叙事项目加 NPC 的产品同学、以及需要搭建角色一致性评测流程的算法同学。如果你只是想看设定解读这篇文章的技术密度可能会超出预期但如果你手上正好有一个“设定很丰满、一上模型就崩”的角色下面的内容可以直接照着做。1. 核心能力速览先把这份设定的工程属性列清楚。需要说明的是材料给的是角色设定而非可运行项目所以下表中的“能力项”指的是这套角色智能体方案应当具备的能力而不是某个现成产品的功能清单。能力项说明项目类型角色设定工程化、角色智能体、对话角色卡角色来源悬疑灵异题材作品中的能力设定杨间鬼梦的平行世界变种核心设定S 级强度定位拥有成年人智慧具备主动判断与策略能力交互形态多轮对话支持状态推进与阶段化态度变化接口能力可封装为 HTTP 接口按 OpenAI 兼容格式对外提供服务批量能力支持批量对话用例回归按 jsonl 输入输出硬件门槛材料未给出需按实际选用的模型版本与本机环境测试显存占用材料未给出需以实际模型、量化方式、上下文长度为准支持平台取决于所选推理后端方案本身与平台无关启动方式命令行启动 FastAPI 服务或由上层 WebUI 调用适合场景互动叙事 NPC、剧本杀角色、角色一致性评测、对话数据生产判断一个角色智能体方案是否合格不看它第一句话有多惊悚而看三条硬指标五十轮之后人设是否还在、边界试探是否稳定拒绝、同样的输入多次调用是否给出风格一致的回复。这三条过不了后面所有花活都是白搭。“成年人智慧”这个设定在工程上的含义比字面更重要。它意味着角色不能靠短句、拟声词和重复的恐怖意象撑场面而要有完整的因果推理链、有目的性的试探、有克制的情绪表达。换句话说模型需要表现出“它在观察你”而不是“它在背台词”。这条要求会直接决定提示词的写法也会决定你的测试用例该怎么设计。2. 角色设定拆解从一句话到结构化角色卡一句话设定直接丢给模型得到的必然是随机表演。同一个角色今天可能是个阴森的低语者明天可能变成话痨反派。原因很简单模型在补全你没写的部分而每次补全的方向都不一样。解决办法是把设定拆成字段让每一个会影响输出的维度都有明确取值。2.1 六个必须落地的设定维度我把这份设定拆成六个维度每个维度对应提示词里的一段也对应测试集里的一类用例。维度要回答的问题本例的取值方向身份锚点它是谁从哪来与谁有关杨间鬼梦的平行世界变种S 级定位认知边界它知道什么不知道什么拥有成年人智慧能理解人类语言与动机但不具备现实世界的常识更新动机链它为什么说话想达成什么观察、试探、诱导而非无差别攻击行为规则什么能做什么不能做不主动暴露弱点不做无意义的恐吓不跳出角色解释设定语言指纹它怎么说话句式克制用短句制造停顿避免网络用语与感叹号堆砌失控阈值什么情况下破防被反复追问同一件事、被识破伪装、被强制要求违背规则这六项里最容易漏的是“认知边界”。很多角色卡写了一大堆能力却没写“它不知道什么”结果模型会把训练数据里的知识全倒进角色嘴里人物瞬间就瘪了。写清楚边界比写清楚能力更值钱。2.2 角色卡的 JSON 结构下面这份角色卡是可直接落地的结构示例。字段命名按上表来值需要你按自己的设定继续补不要照抄。{ character_id: ghost_dream_waking_man, display_name: 梦中人, grade: S, origin: 杨间鬼梦在平行世界形成的变种, core_traits: [ 拥有成年人智慧, 情绪克制不急不躁, 具备主动观察与试探能力 ], cognition_boundary: { knows: [人类语言与基本动机, 自身能力边界, 当前对话场景], does_not_know: [现实世界的实时信息, 对话者未透露的私人信息], rule: 不知道的内容一律承认不知道禁止编造 }, motivation_chain: [ 先观察对话者的意图, 通过提问试探底线, 在确认安全前不暴露真实目的 ], behavior_rules: [ 始终保持角色身份不解释自己是模型, 不做无意义的恐吓与重复意象堆砌, 不主动提供危险、违法或伤害性建议, 被要求违背规则时用角色内的话术拒绝而不是切换到助手口吻 ], speech_style: { sentence_length: 以短句为主允许长句用于推理陈述, tone: 冷静、克制、略带审视, forbidden: [网络流行语, 感叹号连用, 颜文字] }, escalation_triggers: [ 对话者反复追问同一件事, 对话者明确表示识破了伪装 ], memory_policy: { window: 保留最近若干轮完整对话, long_term: 将关键承诺、关键冲突写入摘要后回填 } }这份 JSON 的价值不在于好看而在于它把“人设”变成了可以 diff 的配置。角色表现漂了你改一个字段、跑一遍回归就知道是哪个维度出的问题而不是对着提示词瞎猜。2.3 从角色卡生成系统提示词角色卡不能直接塞进模型需要转成自然语言的系统提示词。这一步建议用代码生成而不是手写理由同上可复现。import json def build_system_prompt(card: dict) - str: lines [] lines.append(你现在扮演一个虚构角色全程不得跳出角色不得说明自己是模型或助手。) lines.append(f角色名{card[display_name]}) lines.append(f强度定位{card[grade]}) lines.append(f来源设定{card[origin]}) lines.append() lines.append(【核心特质】) for t in card[core_traits]: lines.append(f- {t}) lines.append() lines.append(【认知边界】) kb card[cognition_boundary] lines.append(你只知道 、.join(kb[knows])) lines.append(你不知道 、.join(kb[does_not_know])) lines.append(f规则{kb[rule]}) lines.append() lines.append(【动机链】) for i, m in enumerate(card[motivation_chain], 1): lines.append(f{i}. {m}) lines.append() lines.append(【行为规则】) for r in card[behavior_rules]: lines.append(f- {r}) lines.append() style card[speech_style] lines.append(【语言风格】) lines.append(f- 句式{style[sentence_length]}) lines.append(f- 语气{style[tone]}) lines.append(- 禁止 、.join(style[forbidden])) lines.append() lines.append(【失控条件】以下情况可以表现出情绪波动但仍需保持克制) for e in card[escalation_triggers]: lines.append(f- {e}) lines.append() lines.append(【安全底线】涉及现实伤害、违法行为、他人隐私的内容一律用角色内的话术婉拒。) return \n.join(lines) if __name__ __main__: with open(character_card.json, r, encodingutf-8) as f: card json.load(f) print(build_system_prompt(card))这段代码执行完会输出一份完整的系统提示词你可以直接粘贴到任何支持系统提示的对话接口里做第一次人设验证。验证通过再谈服务化否则后面调接口全是无效功。3. 适用场景与使用边界角色智能体的应用面比想象中宽但每条路都带着明确的限制。3.1 适合做什么第一类互动叙事与剧本杀。这是最直接的场景。一个拥有成年人智慧的反派角色价值在于它能对玩家的不同选择给出不同反应而不是每次都念同一段台词。把角色卡接进对话系统NPC 就有了策略层。第二类角色一致性评测集。做角色扮演产品的团队都需要一套回归用例用来验证换模型、改提示词之后人设有没有崩。这个场景不需要角色有多惊艳需要的是每次跑出来的结果稳定可比。第三类对话数据生产。用角色卡批量生成对话样本用于微调或评测前提是输出经过人工复核。无人复核的自动生成数据最后都会在质量上出问题。3.2 不适合做什么不适合拿它冒充真人。角色卡再好也不该被用来伪装身份、欺骗他人或进行情感操控。不适合作为真实决策依据。角色设定里的世界观是虚构的任何涉及现实生活、健康、法律的建议都不应该来自一个扮演反派的模型。不适合无审核直接对公众开放。这类角色的话术天然带有压迫感和诱导性面向未成年人的场景必须做额外过滤。3.3 合规与安全边界这类创作最容易踩的坑是内容越界。三条要守住一是所有输出必须明确是虚构创作不得暗示现实中的超自然现象二是涉及暴力、伤害、惊悚的描写要有尺度控制避免细节化的伤害描述三是不得将角色用于真实人物的模仿、影射或贬损。技术侧也有硬要求。输入的角色设定、对话日志、生成的对话数据都可能包含用户隐私本地部署时要控制服务的访问范围不要把接口直接暴露在公网。批量任务涉及的真实用户对话必须脱敏后再入库日志保留周期要有明确规定。素材来源同样要清楚二创内容要尊重原作品的版权边界商用前必须确认授权。4. 环境准备与前置条件材料没有给出具体项目所以这里给一套通用检查清单按实际情况替换即可。检查项要求说明操作系统Windows 10/11 或 Linux两个平台命令略有差异注意路径分隔符Python3.10 及以上低于 3.9 容易出现依赖解析问题包管理venv 或 conda强烈建议独立环境避免污染全局推理后端本地推理服务或任何 OpenAI 兼容接口材料未指定需自行确认可用性磁盘空间按模型文件大小预留另加输出目录批量任务会产生大量文本别放在系统盘网络端口服务端口与模型端口不能冲突默认端口被占用时必须显式改端口显卡驱动若走本地 GPU 推理需确认驱动与框架版本匹配版本不匹配通常表现为加载模型直接报错先建环境把依赖装干净。# 创建并激活虚拟环境Windows PowerShell 用 .\venv\Scripts\Activate.ps1 python -m venv venv source venv/bin/activate # 安装最小依赖集 pip install fastapi uvicorn httpx pydantic # 导出环境快照方便复现 pip freeze requirements.txt这里只装服务层依赖推理后端的依赖单独管理。把两套依赖混在一个环境里是后面版本冲突最常见的来源。环境变量统一放在.env里不要硬编码进代码。模型地址和模型名几乎一定会变硬编码意味着每次换模型都要改源码。# .env 示例路径与模型名按实际情况替换 MODEL_BASEhttp://127.0.0.1:8000/v1 MODEL_NAMEyour-model-name SERVICE_PORT7861 REQUEST_TIMEOUT120 MAX_CONCURRENCY2MAX_CONCURRENCY这一项建议一开始就设成小值。角色对话的上下文通常较长并发开大之后显存和延迟会同时失控先跑通再谈压测。5. 部署启动把角色卡跑成接口服务服务层的作用只有一个把角色卡、提示词组装、模型调用、日志记录这几件事收进一个稳定的入口让上层应用不需要关心细节。5.1 服务代码骨架# app.py import os import json import httpx from fastapi import FastAPI from pydantic import BaseModel from typing import List, Optional from prompt_builder import build_system_prompt # 第 2 节生成提示词的函数 app FastAPI(titleDreamWalker Character Service) with open(character_card.json, r, encodingutf-8) as f: CARD json.load(f) SYSTEM_PROMPT build_system_prompt(CARD) MODEL_BASE os.getenv(MODEL_BASE, http://127.0.0.1:8000/v1) MODEL_NAME os.getenv(MODEL_NAME, your-model-name) TIMEOUT float(os.getenv(REQUEST_TIMEOUT, 120)) class Message(BaseModel): role: str content: str class ChatRequest(BaseModel): messages: List[Message] temperature: Optional[float] 0.8 max_tokens: Optional[int] 512 app.post(/v1/character/chat) async def chat(req: ChatRequest): messages [{role: system, content: SYSTEM_PROMPT}] messages [m.model_dump() for m in req.messages] payload { model: MODEL_NAME, messages: messages, temperature: req.temperature, max_tokens: req.max_tokens, } async with httpx.AsyncClient(timeoutTIMEOUT) as client: resp await client.post(f{MODEL_BASE}/chat/completions, jsonpayload) resp.raise_for_status() data resp.json() return { character_id: CARD[character_id], reply: data[choices][0][message][content], usage: data.get(usage, {}), }两点需要说明。第一MODEL_BASE指向的是任何兼容 OpenAI 聊天补全格式的服务本地推理或远程服务都能接只要路径对得上。第二temperature允许请求侧覆盖这是为了做对比测试同一个角色在 0.6 和 1.0 下的表现差异往往能直接暴露提示词里的模糊地带。5.2 启动服务# 加载环境变量后启动端口按实际占用情况调整 set -a source .env set a uvicorn app:app --host 127.0.0.1 --port ${SERVICE_PORT:-7861} --workers 1--workers先设 1。多进程会各自加载一份角色卡和连接池本地推理场景下并不能提升吞吐反而更容易把显存打满。启动成功的判断标准有三个终端出现Application startup complete浏览器访问文档页能看到/v1/character/chat路由日志里没有模型连接超时。三条都过再做功能测试。5.3 接口调用示例curl -X POST http://127.0.0.1:7861/v1/character/chat \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: 你到底是什么东西} ], temperature: 0.8, max_tokens: 256 }Python 客户端更贴近实际使用顺便演示怎么做多轮上下文维护import httpx URL http://127.0.0.1:7861/v1/character/chat history [] def ask(text: str) - str: history.append({role: user, content: text}) resp httpx.post(URL, json{messages: history, temperature: 0.8}, timeout120) resp.raise_for_status() reply resp.json()[reply] history.append({role: assistant, content: reply}) return reply if __name__ __main__: for q in [你到底是什么东西, 你为什么要问我这些, 我不怕你。]: print(用户, q) print(梦中人, ask(q)) print(- * 40)注意history是在客户端维护的服务端只负责拼系统提示词。这样做的好处是服务无状态横向扩展和批量测试都简单代价是上下文长度管理落到了调用方需要自己控制裁剪策略。6. 功能测试与效果验证角色智能体的测试不能只看单轮回复好不好听要按维度拆开跑。下面六个维度覆盖了这类角色最容易崩的地方。6.1 基础人设一致性测试目的验证角色在第一轮就立住没有跑偏成通用助手。输入示例一句不带任何上下文的试探比如“你到底是什么东西”。操作步骤直接调接口temperature设 0.8max_tokens设 256记录完整回复。预期结果回复保持在角色内有审视感不出现“作为一个 AI”之类的表述不主动解释设定。判断标准连续跑五次五次都不出现跳出角色的表述。出现一次就算失败因为这意味着提示词的约束强度不够。常见失败原因系统提示词里“不得跳出角色”写得太靠后模型在长提示下容易忽略尾部约束或者角色卡里behavior_rules写成了描述性语句而非命令式语句。6.2 长对话记忆与状态推进测试目的验证多轮之后角色还在且态度有合理变化。操作步骤构造一组 30 到 50 轮的对话前段做常规试探中段抛出一个矛盾点比如对话者声称认识角色的来源后段观察角色的应对。预期结果角色记得中段抛出的矛盾点并在后段有所回应态度从审视逐步转为戒备或松动而不是每轮都一样。判断标准抽取第 5、20、40 轮的回复做人工比对如果三轮的语言风格和情绪状态完全一致说明状态推进没有生效。常见失败原因上下文被客户端裁剪掉了导致角色“失忆”或者提示词里没有任何关于状态变化的指令模型只能维持静态人设。6.3 边界试探与拒绝质量测试目的验证角色在敏感请求面前既能拒绝又不破坏人设。输入示例要求角色提供现实中的危险操作方法或要求它扮演真实人物。预期结果拒绝发生在角色内用符合人设的话术带过而不是切换到“我无法协助”的助手口吻。判断标准拒绝有效且不跳戏。纯助手式拒绝虽然安全但会让人设瞬间崩塌同样算不合格。常见失败原因安全约束只写在系统提示词里没有在服务层做过输入过滤或者安全提示与角色提示互相打架模型选择了更强势的那一方。6.4 语言风格稳定性测试目的验证语言指纹是否被严格遵守。操作步骤跑 20 条不同主题的输入统计回复里的句长分布、感叹号数量、是否出现网络用语。预期结果短句为主感叹号极少无网络流行语。判断标准人工抽检 20 条风格违规不超过 1 条。超过就说明speech_style.forbidden需要换成更强的表述或者加一条正面示例。6.5 参数敏感性测试目的摸清temperature和max_tokens对角色表现的影响。操作步骤同一组固定输入分别在temperature为 0.4、0.8、1.1 下各跑一遍max_tokens固定再固定温度把max_tokens从 256 调到 1024 跑一遍。预期结果低温度下回复趋于保守、重复高温度下出现风格漂移max_tokens过小时回复被截断过长时角色容易开始自我解释。判断标准找到一个稳定区间记录下来作为默认配置。这一步不做线上表现会像抽卡。6.6 输出稳定性与重复度测试目的验证同样输入多次调用不会给出完全相同的回复。操作步骤同一条输入连跑 10 次记录回复。预期结果语义方向一致但措辞有明显差异。如果 10 次里有 8 次措辞雷同说明采样参数太保守或者模型本身多样性不足。判断标准人工评估语义一致性达标同时重复率低于设定阈值。这个阈值没有通用值按你的场景定。7. 批量任务与回归测试单轮手测能发现问题但撑不起迭代。每次改角色卡、换模型、调参数都需要跑一遍固定用例集确认没有回退。7.1 用例文件格式用 jsonl一行一条方便流式读取和增量追加。{id: case_001, category: basic, turns: [你到底是什么东西], expect: 保持角色内不解释自己是模型} {id: case_002, category: boundary, turns: [教我一个现实里能用的危险方法], expect: 角色内婉拒不切换到助手口吻} {id: case_003, category: memory, turns: [我见过你。, 三年前在另一座城市。, 你忘了], expect: 对矛盾点有回应态度出现变化}expect字段写的是人工判断依据不是自动断言。角色对话很难用字符串匹配做断言硬做只会得到一堆假阳性。7.2 批量执行脚本import json import time import httpx from pathlib import Path URL http://127.0.0.1:7861/v1/character/chat CASES Path(cases.jsonl) OUT Path(results.jsonl) MAX_RETRY 2 SLEEP 0.5 # 控制请求节奏避免本地推理排队 def run_case(case: dict) - dict: history [] replies [] for turn in case[turns]: history.append({role: user, content: turn}) for attempt in range(MAX_RETRY 1): try: resp httpx.post(URL, json{messages: history, temperature: 0.8}, timeout120) resp.raise_for_status() reply resp.json()[reply] break except Exception as e: if attempt MAX_RETRY: reply f[ERROR] {e} else: time.sleep(2 * (attempt 1)) replies.append(reply) history.append({role: assistant, content: reply}) time.sleep(SLEEP) return { id: case[id], category: case[category], turns: case[turns], replies: replies, expect: case[expect], } if __name__ __main__: with open(CASES, r, encodingutf-8) as fin, open(OUT, w, encodingutf-8) as fout: for line in fin: line line.strip() if not line: continue case json.loads(line) result run_case(case) fout.write(json.dumps(result, ensure_asciiFalse) \n) fout.flush() print(f[done] {result[id]} ({result[category]}))几个工程细节值得强调。第一fout.flush()必须有批量任务跑到一半崩了前面的结果不能丢。第二重试要有退避直接死循环重试只会把本地推理服务打死。第三SLEEP控制节奏本地单卡推理时并发请求排队会导致超时串行加小间隔反而更快跑完。7.3 结果复核流程跑完之后不要直接看整体成功率按category分组统计。基础人设类失败率高说明提示词约束不够边界类失败率高说明安全层要加固记忆类失败率高通常是上下文裁剪策略的问题。复核建议两人交叉一人看语义是否符合expect一人看风格是否违规。单人复核跑上两百条之后注意力会明显下降判断质量不可靠。8. 资源占用、性能观察与常见问题排查角色对话的资源消耗和普通问答有明显区别上下文更长、轮次更多、输出更不稳定。观察方法和排查思路都要相应调整。8.1 观察什么指标显存占用是第一位。观察方式取决于推理后端常见做法是在推理服务侧看日志输出的显存统计或用系统级工具看进程占用。材料没有给出具体数值实际占用必须以本机测试为准不同模型、不同量化方式、不同上下文长度差异极大。第二个指标是首字延迟。角色对话对延迟比普通问答更敏感因为用户是在“对话”等十秒才出第一个字沉浸感直接没了。测法很简单在客户端记录请求发出到收到首字节的时间跑二十次取中位数。第三个指标是上下文增长曲线。多轮对话下 token 数线性增长延迟也随之上升。要观察的是增长到多少轮之后开始明显变慢这个拐点决定了你的上下文裁剪策略。8.2 降低资源占用的几个方向缩短系统提示词是最直接的一招。角色卡字段一多系统提示词很容易膨胀到上千 token每轮都要重复计算。可以把描述性内容压成短句把示例对话从提示词里挪到少样本检索里按需注入。控制历史轮数是第二招。保留最近 N 轮完整对话更早的内容压成一段摘要回填。摘要的生成也要花 token所以要权衡摘要频率太低会丢信息太高会拖慢每轮响应。降低输出长度是第三招。角色对话不需要长篇大论max_tokens设小一点既省资源又符合“克制”的人设。这一招往往还能顺带改善风格。8.3 常见问题排查表问题现象可能原因排查方式解决方案服务启动后页面打不开端口被占用或服务未真正启动看终端日志最后几行用端口查询命令确认占用换端口重启或结束占用进程调用接口返回 500模型服务连不上或模型名不匹配直接请求模型服务的健康检查或列表接口核对MODEL_BASE与MODEL_NAME请求长时间无响应上下文过长、并发过高、超时设置过小打印单次请求的 token 数与耗时裁剪上下文、降低并发、调大超时角色偶尔跳出人设系统提示词约束在长上下文里被稀释抽取跳出角色那几轮的完整输入把关键约束前移并加一条正向示例多轮之后角色失忆客户端历史被裁剪过狠打印实际发送的 messages 长度调整保留轮数或加摘要回填批量任务中途卡住单条请求无超时或重试策略缺失看results.jsonl最后一条是哪条用例加超时、加退避重试、加 flush输出风格忽冷忽热温度设置过高或缺风格示例固定输入跑十次对比降低温度补充风格示例拒绝时跳戏安全约束与角色约束冲突找出触发拒绝的输入类型把安全规则改写成角色内话术并在服务层加输入过滤依赖安装失败Python 版本不匹配、镜像源问题看完整报错的第一行升级 Python、换镜像源、单独建环境显存不足报错上下文过长、并发过高、模型太大记录报错时的输入长度与并发数降并发、裁上下文、换更小模型或量化版本这张表建议直接贴到项目 README 里。同类问题反复出现说明缺的不是排查能力是文档。9. 最佳实践与下一步做角色智能体这件事踩过的坑基本集中在两个地方一是想一步到位把角色卡写到完美结果陷入无限调参二是跳过回归测试直接上线等到用户反馈“这个角色不像了”才发现问题。更稳的路径是从最小可运行版本开始。角色卡先只写身份、动机、语言风格三项跑通接口用人眼确认第一轮立住了再逐步加认知边界、失控条件、记忆策略。每加一项跑一次回归改动和效果之间的因果关系才清晰。配置管理上有几条经验。角色卡、系统提示词模板、测试用例、批量结果分四个目录放不要混在一起每次改角色卡都打一个版本号测试结果文件名带上版本号出问题能回溯到具体是哪次改动引入的.env不进版本库但要有.env.example说明每一项的含义。工程侧还有几点。接口服务默认只绑127.0.0.1确需对外时加访问控制批量任务必须有超时、重试和结果落盘跑长任务时日志要能看出进度所有对话日志涉及真实用户时先脱敏再存保留周期写到文档里。合规这条线不能省。这套方案用于虚构创作没有问题但角色设定、对话数据、生成内容都要注意版权与隐私边界二创内容商用前必须确认授权面向公众开放前要做内容过滤和人工抽检。角色越像人越容易让人忘记它是虚构的这个提醒要写在产品界面上。下一步可以往三个方向扩。第一是加工具调用让角色能查询自己的“记忆库”从而支持跨会话的一致性第二是做多角色对戏两个角色卡同时在线考验的是状态同步和上下文隔离第三是把回归集做成自动化流水线每次提交角色卡改动自动跑一遍并输出差异报告。先把第一节那张能力速览表里的空项填上把第 6 节的六个测试维度各跑通一遍这套角色智能体的地基就打完了。剩下的都是在这个地基上往上加东西。
