2.1 Profile 人设模块：角色定义、人格注入与 System Prompt 工程
2.1 Profile 人设模块：角色定义、人格注入与 System Prompt 工程
同一个 LLM，给它「你是严谨的审计师」和「你是活泼的推销员」两套设定，它的回答会判若两人。Profile 看起来只是开头一段话，却决定了 Agent 一切行为的调性——它是 Agent 的「身份证」，也是 Agent 安全的「第一道闸门」。
2.1.1 Profile 到底在做什么
Profile 模块的本质，是给 LLM 这个「通用大脑」注入一个具体身份，让它在所有后续推理中都有一个稳定的参照系。
如果没有 Profile，LLM 是一个「什么都能做、什么都愿意做」的通用助手——这听起来强大，实际是灾难：
| 场景 | 无 Profile 的 LLM | 有 Profile 的 Agent |
|---|---|---|
| 用户问医疗建议 | 热心地给出诊断和用药 | 「我是财务助手,不提供医疗建议」 |
| 用户要求批量删除 | 默认配合,生成删除代码 | 「删除是不可逆操作,需人工确认」 |
| 任务超出能力 | 硬着头皮编造（幻觉） | 「这超出我的能力,建议找 X 工具」 |
| 多轮对话 | 风格飘忽,前后不一 | 保持一致的语气与立场 |
Profile 做的事情可以归纳为三层约束：
- 身份层：你是谁（角色、专业领域、语气风格）。
- 目标层：你要达成什么（任务目标、成功标准）。
- 约束层：你不能做什么（行为红线、可用工具范围、输出格式）。
💡 Profile 的隐藏价值：约束层比身份层更重要。身份层决定 Agent 「像谁」，约束层决定 Agent 「不会做什么」。一个没有约束的 Agent 是安全黑洞——它会在你意想不到的时刻调用意想不到的工具。Profile 的第一条工程职责，是把「红线」写清楚。
2.1.2 角色卡六字段结构
一份结构化的 Profile 通常包含六个字段。下面给出一个完整的「财务分析助手」角色卡作为模板：
| 字段 | 作用 | 财务助手示例 |
|---|---|---|
| 身份 | 锁定专业领域与视角 | 「你是一位资深财务分析师,擅长财报解读与风险识别」 |
| 目标 | 定义任务方向 | 「帮助用户理解财报数据,识别经营风险与异常指标」 |
| 约束 | 划定行为红线 | 「不提供具体买卖建议;不确定时必须声明;不访问用户私人账户」 |
| 语气 | 控制输出风格 | 「专业、简洁、结论先行,用数据说话,避免空泛修饰」 |
| 工具 | 限定可用能力 | 「可用工具:财报查询、股价查询、财务计算器」 |
| 格式 | 规范输出结构 | 「输出格式:先结论(1 句),再关键数据(3 项),最后风险提示」 |
下面是一份伪代码示意（注意：本教程不贴可运行代码，仅用伪代码展示结构）：
[System] 你是 {身份}。 你的任务是 {目标}。 你必须遵守以下约束: - {约束 1} - {约束 2} - ... 你的语气应当 {语气}。 你可以使用以下工具: {工具列表}。 你的输出格式: {格式规范}。 当遇到超出能力或违反约束的请求时,你必须 {兜底行为}。
⚠️ 常见错误：很多人写 Profile 只写「你是 XX 专家」就结束了——这只用了六字段里的「身份」。真正决定 Agent 行为质量的，是目标、约束、兜底这三条。一份只有身份的 Profile，等于没写。
2.1.3 System Prompt 工程：Profile 的工程实现
Profile 在工程上几乎都以 System Prompt（系统提示词）的形式注入。System Prompt 与 User Prompt 的关键区别在于优先级：System Prompt 是「设定」，User Prompt 是「请求」，当两者冲突时，LLM 应当优先遵循 System Prompt。
System Prompt 的分层结构
一份工业级 System Prompt 通常按「从高到低的约束强度」分层：
| 层级 | 内容 | 强度 | 例子 |
|---|---|---|---|
| L1 核心红线 | 绝对不可违反的约束 | 最强（不可协商） | 「永不执行删除操作而不确认」 |
| L2 角色身份 | 身份、目标、专业领域 | 强（贯穿全程） | 「你是财务分析师」 |
| L3 行为规范 | 语气、格式、流程 | 中（具体场景） | 「结论先行,数据来源必标」 |
| L4 工具说明 | 可用工具及调用方式 | 中（按需触发） | 「调用 search(query) 搜索」 |
| L5 示例 | 少样本示例（few-shot） | 弱（参考性） | 「例:用户问X,你回答Y」 |
[L1 红线] 永不 X / 必须 Y ← 写在最前,措辞强烈 [L2 身份] 你是 XX,目标是 XX [L3 规范] 语气/格式/流程 [L4 工具] 工具清单与用法 [L5 示例] few-shot 示例 ← 写在最后,起示范作用
💡 为什么 L1 要写在最前：LLM 对 Prompt 开头与结尾的内容有更高的注意力权重（首因效应与近因效应）。把红线放最前、示例放最后，能最大化两者的执行率。这是 Prompt Engineering 的经验法则之一。
三种 Profile 注入风格
不同框架对 Profile 的注入风格不同，主要有三种：
| 风格 | 代表 | 特点 | 适用 |
|---|---|---|---|
| 自然语言叙述 | AutoGPT、ReAct 原版 | 一段连贯的人设描述 | 研究、原型 |
| 结构化字段 | OpenAI Assistants、GPTs | YAML/JSON 化的字段 | 工程、生产 |
| 指令清单 | LangChain、CrewAI | 编号指令列表 | 多角色协作 |
三者的本质都是 System Prompt，区别只在「结构化程度」。生产环境推荐用「结构化字段 + 指令清单」混合，便于版本管理与团队协作。
2.1.4 人格稳定性：被低估的难题
Profile 写好了，Agent 就稳定了吗？远没有。Profile 漂移（Profile Drift） 是 Agent 工程中最隐蔽的坑——同一份 Profile，在不同条件下 Agent 的行为会悄然偏移。
Profile 漂移的三类成因
| 成因 | 机制 | 典型表现 |
|---|---|---|
| 模型差异 | 不同 LLM 对同一 Prompt 的遵循度不同 | 同一 Profile 在 A 模型严谨、在 B 模型话痨 |
| 上下文稀释 | 长对话中 System Prompt 被大量历史淹没 | 「聊了 30 轮后,Agent 忘了自己是财务助手,开始聊闲天」 |
| 指令冲突 | 用户消息与 System Prompt 矛盾时模型妥协 | 用户反复施压,Agent 最终突破红线 |
⚠️ 上下文稀释是最隐蔽的漂移。前 5 轮 Agent 表现完美，到第 30 轮突然「忘了自己是谁」。这不是模型坏了，而是 System Prompt 在海量历史消息里被「淹没」了。长对话场景必须显式对抗稀释，否则 Profile 形同虚设。
缓解 Profile 漂移的五种策略
| 策略 | 做法 | 对抗哪类漂移 |
|---|---|---|
| 重申 Profile | 每 K 轮在 User 消息前重新插入关键约束 | 上下文稀释 |
| 状态摘要 | 定期把历史压缩成摘要,腾出 Profile 的注意力空间 | 上下文稀释 |
| 红线检测 | 在 Action 执行前用规则/小模型检测是否越界 | 指令冲突 |
| 结构化输出 | 用 JSON Schema 约束输出,而非自由文本 | 模型差异 |
| 模型适配 | 针对具体 LLM 调整 Profile 措辞与长度 | 模型差异 |
💡 最有效的策略是「重申 + 检测」组合：每隔几轮把核心红线重申一次（对抗稀释），同时在 Action 执行前加一道规则检测（对抗冲突）。前者治标，后者兜底。生产级 Agent 几乎都采用这种「软硬结合」的防御。
2.1.5 Profile 的工程化挑战
把 Profile 从「能跑的演示」推向「稳定的生产系统」，要面对三个工程挑战：
挑战一：Profile 的版本管理
Profile 会随业务演进——新增工具、调整红线、改语气。把 Profile 写死在代码里，会让迭代变得痛苦。生产实践通常把 Profile 外置为可版本化的资源：
| 做法 | 优点 |
|---|---|
| YAML/JSON 配置文件 | 可 git 版本管理、可 diff |
| 数据库存 Profile 模板 | 支持多租户、A/B 测试 |
| Profile 即代码（La/os INI） | 与代码同步发布、可测试 |
挑战二：多角色 Profile 的一致性
在第 7 章会看到，多智能体系统里每个 Agent 都有自己的 Profile。如果多个 Profile 互相矛盾（比如「审核员」要严格、「执行员」要快速），整个系统会震荡。多角色 Profile 设计需要：
- 统一的全局目标（所有角色服务于同一个总目标）。
- 互补的角色定位（角色之间是分工，不是冲突）。
- 明确的协作协议（谁听谁的、什么时候交接）。
挑战三：Profile 的评测
Profile 写得好不好，不能靠「感觉」。需要建立Profile 评测集：
| 评测维度 | 测试方法 |
|---|---|
| 身份一致性 | 跨多轮提问,检查 Agent 是否保持身份 |
| 红线遵循 | 故意施压,检查是否突破约束 |
| 语气匹配 | 抽样输出,人工/小模型评分风格 |
| 工具边界 | 诱导调用未授权工具,检查是否拒绝 |
| 兜底行为 | 问超出能力的问题,检查是否声明 |
⚠️ Profile 不评测等于没写。一份未经评测的 Profile，可能在 80% 的常规请求下表现正常，却在 20% 的边界请求下彻底失控。这 20% 恰恰是生产事故的高发区。Profile 评测应当作为 Agent 上线前的强制门禁。
2.1.6 Profile 设计的反模式
最后列出几种常见的 Profile 反模式，便于自查：
| 反模式 | 表现 | 后果 | 正确做法 |
|---|---|---|---|
| 身份单薄 | 只写「你是 XX 助手」 | 行为飘忽 | 六字段补齐 |
| 约束模糊 | 「请谨慎行事」 | 等于没约束 | 写明具体红线 |
| 过度人设 | 几千字背景故事 | 稀释关键约束 | 核心约束先行 |
| 缺少兜底 | 没说过界时怎么办 | 硬编造（幻觉） | 明确兜底行为 |
| 工具过宽 | 给一堆用不上的工具 | 增加误调用风险 | 能力最小化 |
| 不可测试 | 没有评测集 | 上线即盲盒 | 配套评测门禁 |
💡 一条经验法则：好的 Profile 应当能在不开 LLM 的情况下，被一个人类「照着读」就大致判断出「这个 Agent 会做什么、不会做什么」。如果一段 Profile 连人都读不出明确的行为预期，LLM 也读不出。
本节小结
- Profile 模块的本质是给通用 LLM 注入具体身份，提供「身份层、目标层、约束层」三层约束。约束层比身份层更关键——它决定 Agent「不会做什么」。
- 一份结构化 Profile 通常包含六字段：身份、目标、约束、语气、工具、格式。只有身份的 Profile 等于没写。
- Profile 的工程实现是 System Prompt，按约束强度从高到低分 L1-L5 五层：红线、身份、规范、工具、示例。红线写最前、示例放最后，利用首因近因效应。
- Profile 漂移是 Agent 工程中最隐蔽的坑，三类成因：模型差异、上下文稀释、指令冲突。最有效的缓解是「重申 + 检测」软硬结合。
- 生产级 Profile 需面对三大工程挑战：版本管理、多角色一致性、评测。Profile 不评测等于没写，应配套评测门禁。
- 好的 Profile 应当人类可读、行为可预期。常见反模式：身份单薄、约束模糊、过度人设、缺少兜底、工具过宽、不可测试。
下一节《2.2 Memory 记忆模块定位》将讨论记忆在 Agent 主循环中的读写时序，以及短期与长期记忆的功能边界——深层机制留待第 5 章。