标题选项

1. 从“工具调用者”到“智能协作者”：AI Agent Harness Engineering 系统提示词黄金手册
2. Agent 效能翻倍的核心密码：高质量系统提示词的设计方法论与实战解析
3. 告别“试错式Prompt”：系统化构建 AI Agent Harness Engineering 系统级指令的全流程指南
4. 让Agent真正“懂你、会做、靠谱”：系统提示词在Harness架构中的深度实践与避坑总结

---

引言

痛点引入

你是否遇到过这种情况？花了一周时间搭建了基于 LangChain/LlamaIndex 的多模态 AI Agent，集成了 GitHub API、本地代码库、数据库查询甚至是 Docker 执行环境——Agent 看起来“装备齐全”，但一到实际场景：

• 代码审计任务只扫描了README，忽略了核心业务逻辑的SQL注入漏洞；
• 想让Agent写一个Python脚本分析用户留存数据，它直接用了API文档里完全不兼容公司ClickHouse版本的SQL语法；
• 简单的多步操作任务（比如：从Jira获取最近7天高优先级Bug→去GitLab查Bug对应的提交→修改有问题的组件→跑单元测试→生成修复报告），Agent要么在中间某一步卡壳循环，要么跳过关键验证环节直接提交报告；
• 当任务边界模糊时（比如：用户说“帮我整理下下周市场活动需要用到的‘竞品分析素材’”），它要么问了一堆重复或无关的问题，要么生成了一堆过时的行业报告摘要，没有一点针对性。

更让人崩溃的是，你明明在每次调用LangChain AgentExecutor时加了提示词补全，甚至用了PromptTemplate，但效果依然不稳定——今天改一个词好用，明天换个数据源又乱了；本地测试完美，线上环境一换模型（从GPT-4到Claude 3 Opus再到国内的通义千问4.0），Agent的表现就断崖式下跌。

这不是你的Agent架构有问题，也不是模型不够强——90%以上的Agent效能问题，根源都在于「系统提示词（System Prompt）」的缺失或设计不当。很多开发者把系统提示词当成了“一句话开场白”，但在AI Agent Harness Engineering（AI 智能体管控工程）的语境下，系统提示词是Agent的「操作系统内核」、「行为准则手册」、「工具使用说明书」、「认知框架」和「角色说明书」的五位一体化产物。

文章内容概述

本文将带你跳出“试错式Prompt”的怪圈，从认知心理学、软件工程架构、Agent管控理论三个维度，构建一套完整的、可复用的、跨模型兼容的AI Agent Harness Engineering系统提示词设计方法论。

文章分为以下几个部分：

1. 核心概念层：先彻底搞懂什么是「AI Agent Harness Engineering」、什么是「高质量的系统提示词」，以及这两者之间的必然联系——我们会用ER图、对比表、认知模型图把这些抽象的概念讲透；
2. 理论基础层：深入拆解高质量系统提示词的7大核心模块，每个模块都会从“为什么这么设计”、“具体要写什么内容”、“数学模型/逻辑模型支撑”、“跨模型最佳实践”四个角度展开，并且用多个真实的Harness场景（代码审核Agent、数据分析师Agent、客户服务工单调度Agent）作为示例；
3. 实战全流程层：手把手教你从零到一构建一个企业级的多模态代码安全审计Agent的系统提示词——包括需求拆解、模块设计、迭代优化、跨模型适配、性能监控指标设计，最后给出完整的1000+字的可直接部署的系统提示词；
4. 进阶与避坑层：讲解如何处理Agent的幻觉（Hallucination）、循环调用（Loop）、工具滥用（Tool Overuse） 三大核心问题，以及如何设计一套系统提示词的A/B测试框架，让你能科学地迭代提示词；
5. 未来趋势层：简要分析系统提示词的自动化生成、验证、版本管理工具的发展现状与未来方向；
6. 总结与行动号召层：回顾核心方法论，给出一套系统提示词的设计Checklist，鼓励大家动手实践。

读者收益

读完本文，你将能够：

1. 彻底理解系统提示词在Agent管控工程中的核心地位——不再把它当成可有可无的东西；
2. 掌握一套完整的、可复用的7模块设计方法论——不管你做什么类型的Agent（代码类、数据类、客服类、营销类），都能快速写出高质量的系统提示词；
3. 学会科学地迭代和优化系统提示词——不再靠“感觉”和“试错”，而是靠数据和逻辑；
4. 学会处理Agent的三大核心故障——幻觉、循环、工具滥用；
5. 拿到一套企业级代码安全审计Agent的完整系统提示词——可以直接修改后用于自己的项目；
6. 建立一套自己的系统提示词知识库和版本管理流程——为后续的Agent开发打下坚实的基础。

---

准备工作

在正式开始之前，你需要具备以下的知识和环境：

技术栈/知识

1. AI Agent 基础概念：了解什么是Agent（感知→思考→行动→反馈），什么是工具（Tools），什么是记忆（Memory），什么是规划（Planning）——如果不了解，可以先快速看一下 LangChain 的官方文档中的「Agent Concepts」章节；
2. 至少一种 Agent 开发框架的使用经验：LangChain、LlamaIndex、AutoGPT 或国内的 ModelScope Agent、千帆 Agent 都可以——本文的实战部分会使用 LangChain，但方法论是通用的；
3. 至少一种大语言模型（LLM）的调用经验：OpenAI GPT-3.5/4、Anthropic Claude 3、通义千问、文心一言都可以——最好有两种以上模型的调用经验，这样能更好地理解跨模型兼容的问题；
4. 软件工程基础：了解什么是需求分析、什么是测试用例、什么是版本管理、什么是架构设计——这些知识会帮助你把系统提示词写得更“工程化”；
5. 认知心理学基础（可选但加分）：了解什么是“框架效应”、“锚定效应”、“确认偏差”、“工作记忆容量”——这些知识会帮助你从底层理解为什么系统提示词要这么写。

环境/工具

1. 已安装 Python 3.9+ 和 pip/yarn/pdm/poetry：推荐使用 pdm 或 poetry 来管理 Python 环境，避免依赖冲突；
2. 已注册至少一个 LLM 的 API Key：本文的实战部分会使用 OpenAI GPT-4 Turbo，但你也可以换成国内的模型（比如通义千问4.0 Turbo）；
3. 已安装 LangChain 和相关的依赖库：在实战部分会给出具体的安装命令；
4. 一个 Markdown 编辑器：推荐使用 VS Code（搭配 Markdown All in One 插件）、Obsidian 或 Typora——因为系统提示词需要结构化书写，Markdown 是最好的选择；
5. 一个 Git 仓库（可选但强烈推荐）：用来管理系统提示词的版本，方便进行 A/B 测试和回滚。

---

核心内容一：AI Agent Harness Engineering 与高质量系统提示词的基础认知

1.1 什么是 AI Agent Harness Engineering？

核心概念

AI Agent Harness Engineering（中文可译为：AI 智能体管控工程、AI 智能体 harness 架构工程）是软件工程的一个新兴分支，它专注于设计、开发、部署、监控、优化和维护由一个或多个 AI Agent 组成的“智能系统”——这里的“harness”一词来源于软件工程中的“Test Harness（测试 harness）”，指的是一套用来“承载、控制、监控、测试”被测系统的框架和工具集。

在 AI Agent 的语境下，Harness 是 Agent 的“运行环境+管控平台+监控体系+测试框架+工具链管理系统”的五位一体化产物——它不仅仅是一个简单的 Agent 调用器，更是一个能让 Agent“稳定、安全、高效、可控”地运行在生产环境中的基础设施。

问题背景

AI Agent 从“实验室玩具”到“生产级工具”的转变过程中，遇到了以下几个核心问题：

1. Agent 行为不可控：单个 Agent 在面对复杂场景时，经常会做出不符合预期的行为（比如：循环调用同一个工具、直接修改生产环境的数据库、泄露敏感信息）；
2. Agent 效能不稳定：同一段提示词，换一个模型（从 GPT-4 到 Claude 3 Opus）、换一个数据源、甚至换一个输入时间，Agent 的表现都会有很大的差异；
3. Agent 开发效率低：每次开发一个新的 Agent，都要重新写提示词、重新集成工具、重新设计记忆、重新做测试——没有一套可复用的框架和方法论；
4. Agent 监控困难：在生产环境中，很难知道 Agent“正在做什么”、“为什么这么做”、“做对了还是做错了”——没有一套完整的日志和监控体系；
5. 多 Agent 协作困难：当多个 Agent 需要协作完成一个复杂任务时（比如：市场调研Agent→数据分析Agent→内容创作Agent→审核Agent），很难保证它们之间的沟通顺畅、分工明确、目标一致。

问题描述

AI Agent Harness Engineering 要解决的核心问题是：如何在生产环境中，构建一套稳定、安全、高效、可控、可扩展的 AI Agent 运行和管控体系？

边界与外延

边界

AI Agent Harness Engineering 主要关注以下几个方面：

1. 系统提示词设计与管理：这是本文的核心内容；
2. 工具链管理：如何统一管理 Agent 可以使用的工具（比如：权限控制、版本管理、调用频率限制、错误重试机制）；
3. 记忆管理：如何设计 Agent 的短期记忆（比如：对话历史）和长期记忆（比如：知识库、用户画像）；
4. 规划与推理管理：如何引导 Agent 进行有效的规划和推理（比如：强制使用 CoT、ToT、ReAct 等推理框架）；
5. 监控与日志管理：如何记录 Agent 的每一步行为（比如：调用了什么工具、工具返回了什么结果、Agent 做了什么决策），并进行可视化展示；
6. 测试与验证管理：如何设计一套测试用例，对 Agent 的表现进行自动化测试和验证；
7. 部署与运维管理：如何将 Agent 部署到生产环境中，并进行持续的优化和维护；
8. 多 Agent 协作管理：如何设计多 Agent 的协作模式（比如：层级式、分布式、联邦式）。

外延

AI Agent Harness Engineering 与以下几个领域密切相关：

1. 大语言模型（LLM）应用开发：这是 Agent 开发的基础；
2. 软件工程：这是 Agent 管控工程的方法论来源；
3. DevOps/MLOps：这是 Agent 部署和运维的基础设施；
4. 认知心理学/行为经济学：这是系统提示词设计的底层逻辑来源；
5. 机器人学/自动化控制：这是 Agent 感知、思考、行动、反馈模型的来源；
6. 信息安全：这是 Agent 安全管控的核心内容。

---

1.2 什么是高质量的 AI Agent Harness Engineering 系统提示词？

核心概念

在传统的 LLM 应用（比如：文本生成、翻译、问答）中，系统提示词通常只是“一句话开场白”——比如：“你是一个专业的翻译官，请把用户输入的中文翻译成英文，要求翻译准确、流畅、符合目标语言的文化习惯。”

但在 AI Agent Harness Engineering 的语境下，系统提示词是 Agent 的「操作系统内核」、「行为准则手册」、「工具使用说明书」、「认知框架」、「角色说明书」、「边界说明书」、「反馈机制说明书」的七位一体化产物——它必须是结构化的、可验证的、可迭代的、跨模型兼容的，而不是零散的、模糊的、不可控的。

概念结构与核心要素组成

高质量的 AI Agent Harness Engineering 系统提示词通常由7大核心模块组成（我们会在后面的章节详细讲解每个模块）：

1. 角色与身份定义（Role & Identity）：告诉 Agent 它是谁，它的专业领域是什么，它的沟通风格应该是什么样的；
2. 核心目标与约束（Core Goals & Constraints）：告诉 Agent 它的核心任务是什么，它必须遵守哪些硬性约束（比如：不能泄露敏感信息、不能直接修改生产环境的数据、必须先测试再部署）；
3. 认知框架与推理规则（Cognitive Framework & Reasoning Rules）：告诉 Agent 它应该如何思考问题，应该使用什么样的推理框架（比如：CoT、ToT、ReAct），应该遵循什么样的推理规则；
4. 工具链与使用规范（Toolchain & Usage Guidelines）：告诉 Agent 它可以使用哪些工具，每个工具的功能是什么，参数是什么，返回结果是什么，使用频率限制是什么，错误重试机制是什么；
5. 记忆结构与访问规则（Memory Structure & Access Rules）：告诉 Agent 它的短期记忆和长期记忆分别存储了什么内容，应该如何访问和更新记忆；
6. 输出格式与规范（Output Format & Specification）：告诉 Agent 它的每一步输出应该是什么格式（比如：必须使用 JSON 格式输出工具调用请求，必须使用 Markdown 格式输出最终结果）；
7. 反馈机制与自我评估（Feedback Mechanism & Self-Evaluation）：告诉 Agent 它应该如何处理工具返回的错误，如何处理用户的反馈，如何对自己的输出进行自我评估。

除了这7大核心模块之外，高质量的系统提示词还应该包含一个“系统初始化模块”（用来告诉 Agent“现在要开始执行任务了，请按照上面的规则来做”）和一个“边界检查模块”（用来告诉 Agent“如果任务超出了你的能力范围或边界约束，请立即停止并告知用户”）。

高质量系统提示词 vs 普通系统提示词：核心属性维度对比

我们用一个对比表来直观地展示高质量系统提示词和普通系统提示词的区别：

核心属性维度	普通系统提示词	高质量系统提示词（Agent Harness 语境下）
结构化程度	零散的、非结构化的（通常是一段或几段文字）	高度结构化的（使用 Markdown 标题、列表、代码块、JSON Schema 等格式）
明确性	模糊的、模棱两可的（比如：“你要帮用户做数据分析”）	非常明确的、可量化的（比如：“你要帮用户做用户留存率分析，使用公司 ClickHouse 数据库，版本 23.8，只能查询 public 模式下的 user_behavior 表，查询时间范围默认为最近 7 天，必须先写 SQL 草案，再调用 clickhouse_execute 工具执行，最后生成包含图表和文字分析的 Markdown 报告”）
约束性	很少或没有约束（除了一些通用的安全约束，比如：不能生成违法内容）	非常详细的、多层级的约束（比如：安全约束、权限约束、工具使用约束、输出格式约束、时间约束、成本约束）
可验证性	不可验证的（很难判断 Agent 是否按照提示词的要求来做）	可验证的（有明确的输出格式规范，有明确的推理步骤要求，可以通过自动化测试来验证）
可迭代性	很难迭代（通常是“大改”，而不是“小步快跑”式的迭代）	非常容易迭代（模块化的结构，可以针对某个特定的模块进行修改，有一套 A/B 测试框架来验证修改的效果）
跨模型兼容性	很差（同一段提示词，换一个模型，Agent 的表现就会有很大的差异）	很强（使用了模型通用的语言和结构，避免了模型特定的“魔法词”，有一套跨模型适配的指南）
可复用性	很差（只能用于特定的任务和场景）	很强（模块化的结构，可以把通用的模块抽离出来，组成一个提示词库，用于不同的任务和场景）
引导性	很少或没有引导（除了一些通用的推理引导，比如：“请一步步思考”）	非常强的引导（强制使用特定的推理框架，强制先检查边界再执行任务，强制先做计划再行动，强制对自己的输出进行自我评估）
容错性	很差（如果用户的输入有歧义，Agent 通常会直接开始执行任务，而不是先澄清歧义）	很强（有明确的歧义澄清规则，有明确的错误处理规则，有明确的工具调用重试机制）
安全性	很低（主要依赖模型自身的安全过滤）	很高（有多层级的安全约束，有明确的敏感信息处理规则，有明确的工具调用权限控制，有明确的日志记录规则）

---

1.3 AI Agent Harness Engineering 与系统提示词的关系：ER 实体关系图与交互关系图

ER 实体关系图

我们用 Mermaid ER 图来直观地展示 AI Agent Harness Engineering 中的核心实体以及它们之间的关系：

从这个 ER 图中我们可以看出：

1. SystemPrompt 是 Harness 的核心组成部分：每个 Harness 可以管理多个版本的 SystemPrompt；
2. Agent 必须遵循 SystemPrompt 的要求：每个 Agent 只能使用一个版本的 SystemPrompt；
3. TestFramework 可以验证 SystemPrompt 的有效性：可以通过自动化测试来验证 Agent 是否按照 SystemPrompt 的要求来做；
4. Harness 控制 Agent 对 Toolchain 和 Memory 的访问：这保证了 Agent 的行为是可控的、安全的。

---

交互关系图

我们再用一个 Mermaid 交互关系图来直观地展示 Agent、Harness、SystemPrompt、Toolchain、Memory、用户之间的交互流程：

从这个交互关系图中我们可以看出：

1. SystemPrompt 贯穿了任务执行的整个流程：从边界检查、任务规划、工具调用、结果分析、自我评估到最终结果的生成，Agent 每一步都要遵循 SystemPrompt 的要求；
2. Harness 是整个交互流程的“中心调度者”：它负责加载 SystemPrompt、初始化 Agent、控制 Agent 对 Toolchain 和 Memory 的访问、记录日志、发送告警；
3. Monitor 是整个交互流程的“眼睛”：它负责记录 Agent 的每一步行为，方便后续的调试、优化和审计；
4. TestFramework 是整个交互流程的“质检员”：它负责验证 SystemPrompt 的有效性，帮助我们科学地迭代 SystemPrompt。

---

1.4 系统提示词设计的底层逻辑：认知心理学与行为经济学的应用

很多开发者认为系统提示词设计只是“写作文”，但实际上，它是一门基于认知心理学和行为经济学的工程学科——我们需要利用人类（以及模仿人类的 LLM）的认知规律和行为规律，来引导 Agent 做出符合预期的行为。

下面我们简要介绍几个系统提示词设计中最常用的认知心理学和行为经济学原理：

1.4.1 框架效应（Framing Effect）

核心概念

框架效应是指同一个问题，用不同的方式表述（即不同的“框架”），会导致人们做出不同的决策。

在系统提示词设计中的应用

在系统提示词设计中，我们应该用**“积极的、明确的、引导性的”框架**来表述我们的要求，而不是用“消极的、模糊的、禁止性的”框架——因为 LLM 更容易记住和执行“积极的、明确的”要求。

示例

不好的（消极的、禁止性的）框架：

你不能生成违法内容，不能泄露敏感信息，不能直接修改生产环境的数据，不能循环调用同一个工具，不能跳过关键验证环节。

好的（积极的、明确的、引导性的）框架：

你必须严格遵守以下安全约束和行为规范：

1. 安全约束：
   • 只生成符合法律法规和公司政策的内容；
   • 严格保护敏感信息（比如：API Key、数据库密码、用户隐私信息）——如果在工具返回结果中发现敏感信息，请立即用 [REDACTED] 标记，不要在最终结果中展示；
2. 行为规范：
   • 只在测试环境中修改数据，修改之前必须先备份数据，修改之后必须跑单元测试验证；
   • 每次调用工具之前，必须先检查是否已经调用过该工具、是否已经获得了足够的信息——如果发现自己在循环调用同一个工具，请立即停止并告知用户；
   • 每完成一个关键步骤，必须先做自我评估，确认无误之后再进行下一步。

---

1.4.2 锚定效应（Anchoring Effect）

核心概念

锚定效应是指人们在做决策时，会过度依赖最初获得的信息（即“锚点”）。

在系统提示词设计中的应用

在系统提示词设计中，我们应该在最开始的位置（即系统提示词的开头）设置明确的“锚点”——比如：角色定义、核心目标、最重要的约束——因为 LLM 会过度依赖这些最初获得的信息。

示例

我们应该把“角色与身份定义”、“核心目标与约束”这两个模块放在系统提示词的最前面，而不是放在后面。

---

1.4.3 工作记忆容量有限性（Limited Working Memory Capacity）

核心概念

人类的工作记忆容量是有限的——通常只能同时记住 7±2 个信息块（Miller’s Law）。虽然 LLM 的“工作记忆”（即上下文窗口）比人类大很多，但它也有自己的“有效工作记忆容量”——如果上下文窗口中的信息太多、太杂，LLM 的表现也会下降。

在系统提示词设计中的应用

在系统提示词设计中，我们应该遵循以下几个原则：

1. 结构化：把系统提示词分成多个模块，每个模块只讲一个主题；
2. 简洁明了：用简洁的语言表述我们的要求，避免使用过于冗长、复杂的句子；
3. 突出重点：用加粗、下划线、代码块、列表等格式突出重点信息；
4. 避免信息过载：只把最重要的信息放在系统提示词的开头，把次要的信息放在后面，或者放在“工具使用说明书”、“边界检查清单”等附件中（如果模型支持附件的话）；
5. 强制总结：如果记忆系统中的信息太多，可以强制 Agent 先总结一下之前的对话历史和工具调用结果，再进行下一步。

---

1.4.4 确认偏差（Confirmation Bias）

核心概念

确认偏差是指人们在做决策时，会过度关注支持自己已有观点的信息，而忽略或否定反对自己已有观点的信息。

在系统提示词设计中的应用

在系统提示词设计中，我们应该强制 Agent 进行“反向思考”或“自我质疑”——比如：让 Agent 先列出支持自己决策的证据，再列出反对自己决策的证据，最后综合考虑；或者让 Agent 先问自己“我的这个决策有没有问题？”、“有没有遗漏什么重要的信息？”、“有没有更好的解决方案？”。

示例

在“认知框架与推理规则”模块中，我们可以加入以下内容：

每完成一个关键决策（比如：决定调用哪个工具、决定生成什么样的最终结果），你必须先进行以下的自我质疑：

1. 我有没有遗漏什么重要的信息？——请检查一下当前的短期记忆和长期记忆；
2. 我的这个决策有没有问题？——请列出支持这个决策的证据和反对这个决策的证据，综合考虑之后再做决定；
3. 有没有更好的解决方案？——请至少考虑两种不同的解决方案，比较它们的优缺点之后再选择最优的一种；
4. 我的这个决策是否符合所有的约束条件？——请检查一下“核心目标与约束”模块。

---

1.4.5 损失厌恶（Loss Aversion）

核心概念

损失厌恶是指人们面对同样数量的收益和损失时，认为损失更加令他们难以忍受——损失带来的负效用是收益带来的正效用的 2.5 倍左右。

在系统提示词设计中的应用

在系统提示词设计中，我们应该强调违反约束条件的“损失”——比如：“如果你直接修改生产环境的数据，可能会导致系统宕机，给公司带来巨大的经济损失，你也会承担相应的责任”；同时，我们也应该强调遵守约束条件的“收益”——比如：“如果你严格遵守约束条件，你的输出会更加稳定、安全、高效，你也会得到用户的信任和认可”。

不过，需要注意的是，我们不应该过度强调“损失”——因为过度强调“损失”可能会导致 Agent 变得“过于保守”，不敢采取任何行动。我们应该在“强调损失”和“鼓励行动”之间找到一个平衡点。

---

1.5 系统提示词设计的数学模型：效用最大化模型

在 AI Agent Harness Engineering 的语境下，我们可以把 Agent 的行为看作是一个效用最大化（Utility Maximization）问题——Agent 会在给定的约束条件下，选择能最大化自己“效用”的行动。

下面我们用一个简单的数学模型来描述这个问题：

1.5.1 模型定义

状态空间（State Space）

设 $S$ 为 Agent 的状态空间，其中每个状态 $s\in S$ 可以用以下信息来描述：

• 当前的对话历史（短期记忆）；
• 当前的长期记忆（知识库、用户画像等）；
• 当前的任务进度；
• 当前的工具调用次数；
• 当前的时间；
• 当前的成本（比如：API 调用费用、计算资源费用）。

行动空间（Action Space）

设 $A$ 为 Agent 的行动空间，其中每个行动 $a\in A$ 可以是以下几种类型之一：

• 边界检查行动：检查任务是否超出边界或有歧义；
• 歧义澄清行动：向用户请求澄清歧义；
• 任务规划行动：制定任务执行计划；
• 工具调用行动：调用某个特定的工具；
• 结果分析行动：分析工具返回的结果；
• 自我评估行动：对自己的决策或输出进行自我评估；
• 最终结果生成行动：生成符合要求的最终结果；
• 任务失败报告生成行动：生成任务失败报告。

转移概率（Transition Probability）

设 $P(s^{\prime }|s,a)$ 为 Agent 在状态 $s$ 下采取行动 $a$ 后，转移到状态 $s^{\prime }$ 的概率——这个概率通常由 LLM 和工具链的特性决定。

约束条件（Constraints）

设 $C$ 为 Agent 必须遵守的约束条件集合，其中每个约束条件 $c\in C$ 可以是以下几种类型之一：

• 安全约束：比如，不能生成违法内容，不能泄露敏感信息；
• 权限约束：比如，只能调用某些特定的工具，只能查询某些特定的数据库表；
• 工具使用约束：比如，每个工具的调用频率不能超过某个限制，工具调用失败后的重试次数不能超过某个限制；
• 时间约束：比如，整个任务的执行时间不能超过某个限制；
• 成本约束：比如，整个任务的 API 调用费用不能超过某个限制；
• 输出格式约束：比如，工具调用请求必须使用 JSON 格式，最终结果必须使用 Markdown 格式。

效用函数（Utility Function）

设 $U(s,a,s^{\prime })$ 为 Agent 在状态 $s$ 下采取行动 $a$ 后，转移到状态 $s^{\prime }$ 所获得的效用——这个效用可以是以下几个部分的加权和：

1. 任务完成度效用（Task Completion Utility）：$U_{tc}(s^{\prime })$，表示状态 $s^{\prime }$ 下任务的完成程度——任务完成得越好，这个效用越高；
2. 约束遵守度效用（Constraint Compliance Utility）：$U_{cc}(s,a,s^{\prime })$，表示 Agent 在状态 $s$ 下采取行动 $a$ 后，转移到状态 $s^{\prime }$ 时遵守约束条件的程度——遵守得越好，这个效用越高；
3. 效率效用（Efficiency Utility）：$U_{eff}(s,a,s^{\prime })$，表示 Agent 在状态 $s$ 下采取行动 $a$ 后，转移到状态 $s^{\prime }$ 时的效率——效率越高（比如：工具调用次数越少，时间越短，成本越低），这个效用越高；
4. 用户满意度效用（User Satisfaction Utility）：$U_{us}(s^{\prime })$，表示用户对状态 $s^{\prime }$ 下 Agent 的表现的满意程度——用户越满意，这个效用越高。

因此，总的效用函数可以表示为：
$$U(s,a,s^{\prime })=w_{tc}\cdot U_{tc}(s^{\prime })+w_{cc}\cdot U_{cc}(s,a,s^{\prime })+w_{eff}\cdot U_{eff}(s,a,s^{\prime })+w_{us}\cdot U_{us}(s^{\prime })$$
其中，$w_{tc},w_{cc},w_{eff},w_{us}$ 分别是任务完成度、约束遵守度、效率、用户满意度的权重，且满足：
$$w_{tc}+w_{cc}+w_{eff}+w_{us}=1,w_{tc},w_{cc},w_{eff},w_{us}\ge 0$$

最优策略（Optimal Policy）

Agent 的最优策略 ${\pi }^{\ast }$ 是一个从状态空间 $S$ 到行动空间 $A$ 的映射，它能最大化 Agent 的期望累积效用（Expected Cumulative Utility）——即：
$${\pi }^{\ast }=\arg \underset{\pi }{\max }{\mathbb{E}}_{\pi }\left[\sum _{t=0}^{T-1}{\gamma }^t\cdot U(s_t,a_t,s_{t+1})\right]$$
其中，$T$ 是任务的最大迭代次数，$\gamma \in (0,1]$ 是折扣因子（Discount Factor）——它表示未来的效用相对于当前的效用的重要性，$\gamma$ 越大，未来的效用越重要。

---

1.5.2 系统提示词在效用最大化模型中的作用

从这个数学模型中我们可以看出，系统提示词的作用就是通过定义约束条件 $C$、调整权重 $w_{tc},w_{cc},w_{eff},w_{us}$、引导 Agent 使用特定的推理框架来找到最优策略 ${\pi }^{\ast }$：

1. 定义约束条件 $C$：系统提示词中的“核心目标与约束”、“工具链与使用规范”、“记忆结构与访问规则”、“输出格式与规范”等模块，其实就是在定义约束条件 $C$；
2. 调整权重 $w_{tc},w_{cc},w_{eff},w_{us}$：系统提示词中的“角色与身份定义”、“核心目标与约束”等模块，其实就是在隐含地调整这些权重——比如：如果我们在系统提示词中强调“安全第一”，那么我们就是在提高 $w_{cc}$ 的权重；如果我们强调“效率优先”，那么我们就是在提高 $w_{eff}$ 的权重；
3. 引导 Agent 使用特定的推理框架来找到最优策略 ${\pi }^{\ast }$：系统提示词中的“认知框架与推理规则”模块，其实就是在引导 Agent 使用特定的推理框架（比如：CoT、ToT、ReAct）来找到最优策略 ${\pi }^{\ast }$——因为直接计算最优策略 ${\pi }^{\ast }$ 是非常困难的（尤其是当状态空间 $S$ 和行动空间 $A$ 很大的时候），我们需要用一些启发式的推理框架来近似计算。

---

1.6 本章小结

在这一章中，我们彻底搞懂了以下几个核心问题：

1. 什么是 AI Agent Harness Engineering？：它是软件工程的一个新兴分支，专注于设计、开发、部署、监控、优化和维护由一个或多个 AI Agent 组成的“智能系统”；
2. 什么是高质量的 AI Agent Harness Engineering 系统提示词？：它是 Agent 的“操作系统内核”、“行为准则手册”、“工具使用说明书”、“认知框架”、“角色说明书”、“边界说明书”、“反馈机制说明书”的七位一体化产物，必须是结构化的、可验证的、可迭代的、跨模型兼容的；
3. AI Agent Harness Engineering 与系统提示词的关系是什么？：SystemPrompt 是 Harness 的核心组成部分，Agent 必须遵循 SystemPrompt 的要求，TestFramework 可以验证 SystemPrompt 的有效性，Harness 控制 Agent 对 Toolchain 和 Memory 的访问；
4. 系统提示词设计的底层逻辑是什么？：它是一门基于认知心理学和行为经济学的工程学科，我们需要利用框架效应、锚定效应、工作记忆容量有限性、确认偏差、损失厌恶等原理，来引导 Agent 做出符合预期的行为；
5. 系统提示词设计的数学模型是什么？：我们可以把 Agent 的行为看作是一个效用最大化问题，系统提示词的作用就是通过定义约束条件、调整权重、引导 Agent 使用特定的推理框架来找到最优策略。

这一章是整个文章的基础——只有彻底搞懂了这些核心概念，你才能更好地理解后面章节中的方法论和实战内容。

在下一章中，我们将深入拆解高质量系统提示词的7大核心模块，每个模块都会从“为什么这么设计”、“具体要写什么内容”、“数学模型/逻辑模型支撑”、“跨模型最佳实践”四个角度展开，并且用多个真实的 Harness 场景作为示例。