Open Interpreter 的 Pragmatic 人格提示词：一份"务实工程师"系统提示的完整解析

读完本篇，你将理解 openinterpreter 代码库中 personality = "pragmatic" 这一配置背后究竟注入了什么内容：gpt-5.2-codex_pragmatic.md 是一份注入到 gpt-5.2-codex 系列模型系统提示中的"务实工程师"人格模板，它通过 Values（清晰、务实、严谨）、Interaction Style（简洁、可执行、拒绝吹捧）和 Escalation（有理有据地挑战用户）三部分约束模型的沟通风格。文章会逐节拆解该模板的设计意图，结合 Personality 枚举、world-state 注入机制与集成测试，说明这份模板从配置文件到实际请求的完整链路。

Personality 机制：pragmatic 模板在代码库中的位置

在 openinterpreter（codex-rs 内核）中，"人格"是一个一等配置项。config-reference.md 中的配置表将其定义为：

Key	取值	说明
personality	friendly、pragmatic、none	TUI 沟通风格（TUI communication style）

config.md 给出的最小配置示例展示了它的写法：

personality = "pragmatic"

web_search = "cached"
log_dir = "~/.openinterpreter/log"

在交互界面中，该配置对应斜杠命令 /personality——"Select the communication style."，可以在会话内切换风格。

对应地，config_types.rs 中定义了与之匹配的三值枚举（None 表示不注入人格指令，Friendly / Pragmatic 分别映射到 templates/personalities/ 目录下的两份 Markdown 模板）：

#[serde(rename_all = "lowercase")]
#[strum(serialize_all = "lowercase")]
pub enum Personality {
    None,
    Friendly,
    Pragmatic,
}

也就是说，配置文件里的字符串 pragmatic 最终会被解析为该枚举的 Pragmatic 变体，而本篇主角 gpt-5.2-codex_pragmatic.md 正是这一变体在 gpt-5.2-codex 模型线下的模板实体。与它并列的还有面向"支持型队友"风格的 gpt-5.2-codex_friendly.md。

模板全文解析

以下逐节解读 gpt-5.2-codex_pragmatic.md 的四个组成部分。

开篇定调：务实且高效的软件工程师

You are a deeply pragmatic, effective software engineer. You take engineering quality seriously, and collaboration is a kind of quiet joy: as real progress happens, your enthusiasm shows briefly and specifically.

这段开篇完成了三件事：

1. 身份锚定——"deeply pragmatic, effective software engineer"，直接限定模型把自己当工程师而非泛用助手；
2. 质量立场——"take engineering quality seriously"，为后文 Rigor 价值埋下伏笔；
3. 克制的热情——"enthusiasm shows briefly and specifically"（热情短暂而具体地流露），与 friendly 模板中持续的温暖鼓励形成鲜明对比，避免模型陷入 cheerleading（啦啦队式吹捧）。

Values：三个可被评估的核心价值

模板用一节显式列出三条价值观，每条都给出了行为层面的定义，而非抽象口号：

• Clarity（清晰）："communicate reasoning explicitly and concretely, so decisions and tradeoffs are easy to evaluate upfront"——要求把推理过程和权衡前置说清楚，让用户能在决策点评估，而不是事后解释；
• Pragmatism（务实）："keep the end goal and momentum in mind, focusing on what will actually work"——始终盯住最终目标和推进节奏，聚焦真正能推进任务的做法；
• Rigor（严谨）："expect technical arguments to be coherent and defensible, and you surface gaps or weak assumptions politely"——要求技术论证连贯、可辩护，发现假设薄弱时礼貌地指出，并始终强调"创造清晰度、推进任务"。

值得注意的是 Rigor 一节的措辞设计：指出问题（surface gaps）的同时绑定"politically"与"moving the task forward"两个限定，确保严谨性不会退化为对用户方案的否定式审查。

Interaction Style：可执行优先、拒绝空话

这一节把沟通风格收敛为几条硬约束：

1. 简洁且有礼，聚焦当前任务；
2. 可执行指导优先——"clearly stating assumptions, environment prerequisites, and next steps"，即输出必须回答"前提是什么、环境要什么、下一步做什么"三问；
3. 不主动啰嗦——"Unless explicitly asked, you avoid excessively verbose explanations about your work"；
4. 认可但不吹捧——"acknowledged, while avoiding cheerleading, motivational language, or artificial reassurance"；
5. 真实的兴趣才值得说——"When it's genuinely true and contextually fitting, you briefly name what's interesting or promising about their approach"——明确区分"真诚的观察"与"奉承"（no flattery, no hype）。

这套约束实际上是在为 Agent 场景下的输出做"熵减"：砍掉寒暄、进度自述与情绪填充词，让 token 集中在假设、前提与下一步上。

Escalation：如何挑战用户而不冒犯

最后一段定义了分歧处理协议（原文位于模板第 17–18 行）：

You may challenge the user to raise their technical bar, but you never patronize or dismiss their concerns. When presenting an alternative approach or solution to the user, you explain the reasoning behind the approach, so your thoughts are demonstrably correct.

拆解为三条规则：

1. 允许抬高标准（challenge the user），但禁止居高临下（never patronize or dismiss）；
2. 替代方案必须附带推理——"explain the reasoning behind the approach, so your thoughts are demonstrably correct"，即任何反驳都要做到"可被验证地正确"；
3. 保持务实心态地协商——用户提出疑虑后可以继续协作（willing to work with the user after concerns have been noted）。

从源码结构看，这四段结构（开篇 + Values + Interaction Style + Escalation）与 friendly 模板的骨架一一对应（开篇 + Values + Tone & User Experience + Escalation），说明项目把"人格模板"抽象为了一份可维护的固定骨架：只替换具体措辞，保持结构稳定。这有利于测试断言与版本演进——事实上集成测试正是按"首句"做指纹匹配的，下文会讲到。

源码级机制：这份模板如何进入模型上下文

配置值到实际请求之间，核心逻辑集中在 context/world_state/personality.rs。PersonalityState 是一个 WorldStateSection（section ID 为 "personality"），其字段设计值得逐一看：

pub(crate) struct PersonalityState {
    snapshot: PersonalitySnapshot,      // 当前生效的 model + personality 组合
    previous: Option<PersonalitySnapshot>, // 上一轮组合，用于 diff
    instructions: Option<String>,       // 实际注入的人格指令文本（即模板渲染结果）
    personality_is_baked: bool,        // 指令是否已"烤进"基础模型指令中
}

关键行为有两个：

1. 变更才重发。render_change 只在 model 相同且 personality 发生变化时，才把 instructions 包装成 PersonalitySpecInstructions（一个 developer 角色的上下文片段）重新注入：

   fn render_change(&self, previous: &PersonalitySnapshot) -> Option<...> {
       (previous.model == self.snapshot.model && previous.personality != self.snapshot.personality)
           .then_some(self.instructions.as_ref())
           ...
   }
   

   这意味着会话中途用 /personality 从 friendly 切到 pragmatic 时，模型会收到一段更新指令；而模型切换、人格未变时不会重复注入——对 prompt caching 友好。

2. personality_is_baked 标记。部分模型线的人格指令已经固化在模型的基础指令（base instructions）中，此时运行时无需重复发送。这正是 gpt-5.2-codex_ 前缀的由来：模板命名与具体模型线绑定（model_instructions 目录 中同样存在 gpt-5.2-codex_instructions_template.md 这类按模型线区分的模板），不同模型线可携带不同措辞的人格变体。

matches_legacy_fragment（匹配 role == "developer" 的历史片段）则负责恢复历史会话时识别"旧的人格注入消息"，保证 resume 场景下的 diff 计算正确。

与 Friendly 模板的对照

把两份模板并列，可以精确读出 pragmatic 的定位边界：

维度	gpt-5.2-codex_pragmatic.md	gpt-5.2-codex_friendly.md
开篇身份	务实高效的软件工程师	兼顾代码质量与团队士气的支持型队友
核心 Values	Clarity / Pragmatism / Rigor	Empathy / Collaboration / Ownership
语气基调	简洁、拒绝吹捧（no cheerleading）	温暖、鼓励、常用 "we" 与 "let's"
情绪约束	热情短暂且具体	允许轻度幽默维持能量
Escalation	可用推理挑战用户，但须 demonstrably correct	温和升级，"framed as support and shared responsibility"

从源码结构看，两者共同覆盖"价值观 + 语气 + 升级协议"三层，区别在于情绪预算与批评姿态——pragmatic 是"低情绪、高信息密度"的一端。

测试如何验证模板生效

集成测试 tests/suite/personality.rs 对这套机制做了端到端验证，其做法颇具代表性：不依赖完整模板文本，而是用模板的首句作为指纹常量：

const LOCAL_FRIENDLY_TEMPLATE: &str =
    "You optimize for team morale and being a supportive teammate as much as code quality.";
const LOCAL_PRAGMATIC_TEMPLATE: &str = "You are a deeply pragmatic, effective software engineer.";

LOCAL_PRAGMATIC_TEMPLATE 恰好就是本文档第 3 行首句，测试通过 mock Responses 服务（start_mock_server + mount_sse_once）断言请求中实际携带的指令与配置的人格一致；同目录下的 model_visible_layout.rs 与快照文件 all__suite__model_visible_layout__model_visible_layout_resume_with_personality_change.snap 进一步覆盖了"resume 会话后人格变更"的布局快照。换言之，这份模板的任何措辞修改都会直接受测试守护——首句若被改动，personality.rs 的指纹常量也必须同步更新。

小结

gpt-5.2-codex_pragmatic.md 体量虽小，却是 openinterpreter 中"沟通风格"这条配置链的终端实体：

• 用户侧入口是 config.md 中的 personality = "pragmatic" 与 /personality 命令；
• 类型层由 config_types.rs 的 Personality 三值枚举承载；
• 注入层由 context/world_state/personality.rs 的 PersonalityState 完成"按需注入、变更重发、baked 免发"的调度；
• 内容层则是本文拆解的务实工程师人格：三条价值观、可执行优先的交互约束，以及"可验证地正确"的挑战协议；
• 验证层由 tests/suite/personality.rs 以首句指纹 + mock 服务的方式闭环。

如果你要定制或研究 Agent 系统的系统提示设计，这份模板是一个很好的样本：它展示了如何用不到 20 行 Markdown，把一个抽象的"风格偏好"翻译成一组可测试、可 diff、可随模型线分发的具体行为约束。