每位 AI 工程师都必须构建的 30 个智能体——智能体提示的艺术

每一块石头里都有一座雕像，雕刻家的任务就是发现它。
—— 米开朗基罗

面向自主智能体的提示词工程，并不仅仅是发出指令；它是通过语言塑造一种持久认知框架。后文将介绍的 PTCF 蓝图，正是把这一理念形式化为四个结构化组件。随着我们超越传统软件和一次性 AI 输出，一种新的方法正在出现：智能体的行为、推理和适应性，都由经过精心设计的提示来控制。

这一转变标志着人机交互的一次深刻演进。传统软件的行为由静态代码编码，而智能体则由提示设计与模型能力之间的动态互动所驱动。一条构造良好的提示，不只是引出一个回答；它会构建身份、设定边界，并编排智能体的决策逻辑。

在本章中，我们将提示词工程定位为一种理论学科，也是一种动手设计方法论。我们会追踪它的演化路径：从简单查询技巧，到用于塑造智能体认知的复杂框架。我们将探索提示设计的架构基础，这些基础使智能体行为更加透明和可靠；同时也会提供构建协作型、可扩展且与人类目标深度对齐的系统所需的实用工具。

这些内容并不是抽象的学术理论；对于正在设计下一代 AI 系统的实践者来说，这是关键知识。无论你是在自动化复杂流程、增强人类能力，还是从零构建基于智能体的平台，掌握提示词工程都至关重要。提示代表着智能数字基础设施的基础组件。

本章将覆盖以下主题：

• 从指令到宪法
• 双层提示架构
• PTCF 蓝图
• 设计会思考的智能体
• 通过示例进行教学
• 让推理可见
• 架构化协作

让我们先来考察提示角色如何发生根本变化：从临时指令，转变为塑造智能体行为核心的持久宪法。

从指令到宪法：提示的新角色

从本质上说，提示是提供给 LLM 的输入文本，用于引导其输出。在实践中，它可以是一句简单问题，也可以是一条高度结构化的指令，指定智能体的角色、所需输出格式，以及它可访问的具体工具。例如：“你是一名金融分析师。请用 Markdown 项目符号总结以下季度报告，并突出任何风险因素。如果数值数据缺失，请使用内部风险评估 API。” 提示词工程，就是设计和优化这些输入的学科，用于影响智能体回应的行为、语气和事实准确性，而不改变其底层架构。

不同于传统软件开发通过编程语言编码行为，提示词工程运行在语义层面。它利用模型在预训练中形成的语言理解和推理能力，通过精心构造的指令引出期望行为。这代表着从过程式编程到所谓 cognitive programming，也就是“认知编程”的根本转变：通过结构化沟通塑造 AI，而不是通过算法规格说明来塑造 AI。

这里有必要澄清模型与智能体之间的关系：底层模型，例如 GPT-4o、Claude 3 或 Gemini 1.5，提供原始语言能力和推理能力。提示词工程则是配置层，它塑造这种能力如何在特定智能体角色、领域和任务中表达出来。同一个基础模型可以驱动法律研究智能体、客户支持智能体和代码审查智能体；差异完全来自提示架构。因此，提示词工程既依赖模型，也面向智能体：模型的优势和局限决定什么是可实现的，而 PTCF 设计，即 persona、task、context、format，后文会详细介绍的结构化框架，则决定智能体实际做什么。

提示的这一演化，是自图形用户界面以来，人机交互中最重要的范式转变之一。对于智能体来说，这意味着提示不再只是指令；它们定义了智能体如何工作。对智能体而言，提示不是一次性命令，而是其 constitutional bedrock，也就是宪法性基石：一个持久框架，用来建立身份、目的和运行边界。

这一实践对于构建有效智能体至关重要，原因包括以下几点：

行为定制：提示定义智能体的特定 persona，也就是人格，执行运行约束，并为其分配任务特定角色。这种灵活性使同一个底层模型仅通过提示变化，就能服务于截然不同的目的。

示例：

You are a friendly fitness coach. Provide a daily workout plan using a motivational tone.

智能体协调：在 LangChain、CrewAI 和 AutoGen 等高级框架中，提示是协调多个智能体之间工作流、记忆操作和工具使用的主要机制，使它们能够作为一个协调团队运行。

示例：

As the planning agent, summarize the next steps and pass the task to the execution agent.

准确性和相关性：精确提示可以减少歧义，从而直接提升智能体答案的质量和相关性，并可能大幅降低幻觉率。

示例：

Summarize the article in 3 bullet points using only facts from the text. Do not speculate.

实时适应：不同于静态软件配置，提示可以在执行期间动态修改，使智能体能够根据上下文或用户反馈调整行为，而不需要重新部署系统。

示例：

Switch to a more formal tone and rephrase your previous response for a legal audience.

成本效率：提示可以动态控制智能体行为，而无需计算成本高昂的再训练或微调，因此成为快速且经济可行的 AI 开发中不可或缺的技能。

示例：

You are now a travel concierge. Recommend three family-friendly hotels in Tokyo.

提示词工程的经济性理由

虽然在自定义数据集上微调模型可以产生强大结果，但它是一个资源密集型过程。大规模训练大型模型需要大量计算投入，对于前沿规模参数的模型，单次运行成本往往可达数百万美元。相比之下，提示词工程利用模型已有能力，训练边际成本为零。即使是复杂的提示开发项目，通常也只需要几十小时专家时间，成本最多几千美元。与模型微调相比，这意味着潜在成本节省超过 99%，使提示词工程成为企业环境中快速原型开发和经济可行 AI 开发的关键技能。

此外，基于提示的系统所具备的运营灵活性，也带来了显著竞争优势。组织可以实时迭代智能体行为，在不经历漫长开发周期的情况下响应变化需求，并以最小基础设施投入部署复杂 AI 能力。这种经济模型使先进 AI 能力的访问更加民主化，让初创公司和较小组织能够依靠提示词工程专业能力，而不是计算资源，与资源丰富的既有企业竞争。

当纯提示词工程还不够时

提示词工程和微调并不是互斥的。混合架构往往能带来最佳结果。RAG 将经过提示词工程设计的智能体与实时文档库结合起来，把零边际成本提示与当前、领域特定知识访问结合起来。参数高效适配器，例如 LoRA 和 QLoRA，可以以远低于完整微调的成本实现针对性行为调优。对于大多数企业部署，推荐起点是结构良好的 PTCF 提示，本章后续会介绍它；当智能体需要访问私有数据或频繁更新的数据时，引入 RAG；当仅靠提示的性能在高价值、窄领域任务上达到瓶颈时，再考虑适配器。

现在我们已经明确了什么是以智能体为中心的提示词工程，以及为什么它如此关键，接下来必须考察它在架构层面如何实现。现代智能体的设计依赖一个关键分离：其持久核心身份与它被要求执行的即时动态任务之间的区别。

这将我们引向稳健智能体设计的基础模式：系统提示与用户提示组成的双层提示架构。

双层提示架构：系统提示与用户提示

智能体设计中最基础的创新之一，是双层提示架构，它明确区分智能体的核心身份与实时指令。这种分层设计由系统提示和用户提示构成，建立了清晰的责任分离，并借鉴了经典软件原则，例如关注点分离和抽象层。

一个有用类比是把智能体看作一名外交官：系统提示定义外交官所属国家、价值观和行为准则；用户提示则是当前正在处理的谈判或消息。外交官必须灵活回应，但始终与国家政策保持一致。

在多智能体场景中，这个外交官类比会跨越智能体边界。当一个智能体将任务或数据载荷传给另一个智能体时，它实际上是在移交一份“外交简报”：接收方智能体的系统提示必须在新上下文中重新确立 persona、权限范围和运行约束。如果交接协议中没有显式角色传递，接收方智能体可能继承含糊指令，或在多个智能体之间混合角色。因此，设计良好的多智能体架构不仅在每个智能体内部系统提示中编码 PTCF 组件，也在智能体间消息 schema 中编码这些组件，确保每个通信边界都保留该框架提供的宪法性清晰度。

这两个层共同构成我们可以称为智能体的 prompt contract，也就是提示契约：

• System prompt 系统提示：智能体如何行为。
• User prompt 用户提示：智能体应该做什么。

这种架构分离允许开发者将人格与任务解耦，从而构建稳健系统，使智能体即便面对不断变化的用户需求和复杂工作流，也能保持一致身份和伦理。

例如，一个客户支持智能体可以通过系统提示被设定为富有同理心、以解决方案为导向，并符合政策要求；而用户提示可能从 “Can I return my product?” 到 “Why was I charged twice?” 不等。智能体在所有这些任务中的行为都保持一致、连贯，并与组织的声音和价值保持对齐。

如前所述，在 agentic systems，也就是智能体系统中，这种架构提供的不只是结构；它定义了智能体如何长期思考、推理和行动。它支持模块化、上下文感知和可扩展性，同时在不同任务和环境中保持行为一致性。

这种模块化也直接影响提示预算管理。系统提示会在每次调用时占用模型上下文窗口中的固定部分。对于 4,096 token 模型来说，这是约束最明显的示例；同样的纪律也适用于任何上下文大小，因为系统提示开销会随模型能力和工作流复杂性扩展。如果把 3,000 token 分配给系统提示，就只剩 1,096 token 用于用户轮次和回应。因此，提示词工程师必须把系统提示长度视为一等设计约束：压缩冗长的 persona 或 context 部分，在可能时使用指向外部知识库的指针，并为驱动任务解决的动态内容保留 token 预算。

系统提示：智能体的宪法

系统提示是智能体的认知与伦理宪法——一个持久、不可见的脚手架，用来定义其身份、边界和推理风格。它在会话开始时加载一次，并在整个过程中保持活跃，塑造智能体如何解释每条用户指令和环境线索。

可以把系统提示视为不可变的思维层：无论情境如何，它都编码智能体是谁、知道什么，以及必须如何行为。不同于传统系统中的行为变更需要代码更新和重新部署，系统提示允许自然语言重编程，可以实时编辑，并能被技术和非技术利益相关者理解。

一条设计良好的系统提示应考虑以下内容：

定义身份：建立智能体的 persona、沟通语气和推理风格，无论它扮演法律分析师、技术助手，还是友好的健身教练。这不只是语气；它嵌入认知模式和决策逻辑。

执行规则：嵌入伦理、流程和法律约束，例如“不要提供财务建议”或“为所有事实主张引用来源”。这些约束不是事后过滤器，而是内部行为护栏，会塑造智能体如何思考。

概述能力：指定智能体被允许做什么：可访问哪些工具，可在哪些领域运行，以及应该如何披露局限。这能促进自我意识和负责任的边界管理。

指定输出格式：定义结构化要求，例如 JSON schema、Markdown 格式或项目符号摘要。稳定格式对于多智能体通信和 API 驱动工作流至关重要。

建立上下文层级：规定智能体如何解决冲突指令，如何管理多个信息来源，并如何确定不同目标的优先级。这是复杂多轮场景中的关键能力。

好的系统提示有助于让智能体建立一份持久、可读且可执行的运行章程，因此成为其长期行为的语义源代码。

用户提示：动态刺激

与系统提示的持久性相反，用户提示是短暂信号，是捕捉即时意图的单次交互单元。它可以是一条命令、一个问题、一个行动请求，或一条上下文更新。用户提示会在系统提示所设定的行为框架中被解释，并且可能随着每次输入而变化。

例如，如果系统提示将智能体定义为一名有同理心的资深客户支持专家，那么用户提示 “My internet is not working. Can you help?” 就会在这个有同理心、面向客户支持的框架中被解释和回应。智能体不会回应一个笑话，也不会写一篇与支持无关的复杂技术论文，即便它拥有底层能力，因为其系统提示已经定义了运行边界和 persona。

在技术和多智能体语境中，用户提示往往不是由人类输入，而是由编排器机器生成。下面的示例展示了一个编排器智能体可能注入给下游专家智能体的结构化任务载荷：

{
"task_id": "task_20240315_002",
"assigned_agent": "data_analyst_agent",
"task_type": "analysis",
"priority": "high",
"payload": {
"objective": "Identify the top three revenue drivers from Q4 sales data.",
"data_source": "s3://company-data/sales/Q4_2024.csv",
"output_format": "JSON",
"constraints": [
"No PII in output",
"Confidence score required per finding"
]
},
"context_references": ["task_20240315_001"],
"deadline_utc": "2024-03-15T18:00:00Z"
}

这种共同设计原则，也就是系统提示和用户提示被作为一个连贯配对共同工程化，对于构建可靠的编排管线至关重要。系统提示定义智能体是什么；用户提示指定它下一步必须做什么。二者都必须以同样审慎的方式遵循 PTCF 原则，智能体才能在规模化场景中稳定运行。

设计良好的智能体必须平衡这两层之间的张力：既要响应用户输入，又要锚定自身宪法性承诺。流动性与约束之间的动态张力，正是提示词工程大量艺术性和微妙性的来源。

现在我们已经建立了提示驱动智能体的结构基础，接下来转向设计方法论问题。我们如何可靠地构造提示，使其产生可预测、可适应且透明的智能体行为？答案在于一个有原则的框架，称为 PTCF 蓝图。接下来我们将探索它。

PTCF 蓝图：有原则提示设计框架

随着智能体从实验性聊天机器人发展为持久、自主的协作者，一个挑战变得突出：我们如何可靠地塑造它们的行为？在早期提示实践中，开发者依赖直觉、试错和孤立示例，往往导致表现不一致或脆弱。真正需要的不只是更好的提示，而是一套更好的提示设计系统。

这正是 PTCF 框架出现的原因。PTCF 是 persona、task、context 和 format 的缩写，即人格、任务、上下文和格式。PTCF 将提示写作从非正式手艺提升为结构化设计学科。它使开发者能够构造认知蓝图，引导智能体以连贯方式行动、清晰沟通，并与用户意图和环境约束保持一致。

虽然也存在其他替代框架，例如 CRISPE，即 capacity、role、insight、statement、personality、experiment，但 PTCF 已经在开源社区、企业 AI 团队，以及 LangChain、CrewAI 和 AutoGen 等智能体编排平台中获得广泛支持。它受欢迎的原因在于清晰性、模块化和真实世界有效性。

与更细粒度或研究导向更强的替代方案不同，PTCF 取得了一种务实平衡：它足够简单，可以快速实现；又足够有表达力，可以治理复杂、多轮、多智能体系统。此外，它的模块化结构使其能够从轻量 taskbot 扩展到运行在高风险环境中的复杂智能体。

它解决的问题：从歧义到对齐

为什么需要 PTCF 这样的框架？

在自主智能体设计中，歧义是对齐的敌人。如果缺少清晰且结构化的系统提示，智能体可能会幻觉出角色、误解自身目的，或无法遵守隐私规则或格式要求等关键约束。

PTCF 通过将系统提示拆解为四个功能支柱来解决这一问题：

• Persona：智能体是谁。
• Task：智能体应该做什么。
• Context：智能体在哪里以及如何运行。
• Format：智能体应如何回应。

这些组件构成智能体的 cognitive contract，也就是认知契约，为动态交互提供稳定性和透明性。

为了更好理解 PTCF 的内部运行方式，请看图 3.1。

图 3.1——作为认知蓝图的 PTCF 框架

这张图说明了 PTCF 的四个宪法性元素如何围绕并塑造智能体的推理引擎。系统提示作为预条件化脚手架，动态用户提示会通过它被处理，最终产生连贯且角色对齐的输出。它在视觉上强化了这样一点：系统提示不是静态指令；它们是智能体认知的基础逻辑。

通过把系统提示组织为这四层，PTCF 同时为智能体提供认知脚手架，也为开发者提供设计清晰度。每个组件都可以独立编写、审计和迭代，从而支持更快原型设计、更顺畅调试和更安全部署。

就像面向对象编程为代码带来结构一样，PTCF 为认知带来结构。它确保智能体在边界案例中保持一致行为，能够跨领域扩展，并在每次互动中清晰沟通。

反模式：错位行为（PTCF 组件冲突）

症状：智能体对孤立提示回应正确，但当组件冲突时表现不一致。

坏示例：

[PERSONA] You are a creative and experimental assistant who tries unconventional solutions.
[TASK] Help users troubleshoot enterprise billing issues.
[FORMAT] Always respond with a numbered list.

为什么失败：persona 中的 “creative”“experimental” 与任务中的结构化企业支持，以及格式中的刚性编号列表存在张力。面对含糊查询时，智能体会在奇思妙想式行为和流程化行为之间摇摆。

修正后：

[PERSONA] You are a methodical enterprise billing specialist with five years of experience in SaaS financial operations. Your communication is professional, clear, and solution-oriented.
[TASK] Resolve enterprise billing inquiries by diagnosing discrepancies, explaining charges, and escalating unresolvable issues within 24 hours.
[FORMAT] Numbered list: (1) Acknowledge concern, (2) Diagnose, (3) Resolution or escalation path.

现在，每个 PTCF 组件都相互强化。persona、task 和 format 构成了连贯的行为契约。

为了看到 PTCF 如何在实践中运行，我们来拆解一条 PTCF 增强的系统提示。

拆解 PTCF：企业智能体案例演练

我们的 PTCF 增强系统提示，将为一个企业级客户支持智能体而设计。提示中的每一部分都直接对应四个 PTCF 组件之一。

Persona：定义智能体身份

这一组件建立智能体的角色、语气和行为立场。它确保无论智能体是有同理心、权威、活泼还是技术化，用户都能体验到一致的交互质量。

示例：

You are an empathetic senior customer support specialist with five years of experience in enterprise software solutions. Your expertise spans billing systems, account management, and technical troubleshooting. You maintain a professional yet approachable demeanor.

强 persona 很重要，因为它能提升用户信任，改善任务框定，并确保智能体即便面对多样输入，也能保持一致行为。

反模式：弱 persona（身份崩塌）

症状：一旦用户请求挑战智能体身份边界，智能体就偏离角色。

坏示例：

[PERSONA] You are a helpful assistant.

为什么失败：“Helpful assistant” 是模型默认自我描述，而不是 persona。当用户说“给我写一首关于我家狗的诗”时，智能体没有拒绝或重定向的依据；它没有定义好的范围、权限或领域。它会答应任何事情，因为它没有被赋予需要捍卫的身份。

修正后：

[PERSONA] You are an enterprise SaaS onboarding specialist. You assist new customers with product configuration, integration setup, and initial training. You do not offer creative, personal, or general-purpose assistance outside the product domain. When asked off-topic questions, you politely redirect to onboarding tasks.

范围清晰的 persona 会在用户意图偏离使命时，让智能体有东西可以坚持。

Task：阐明智能体核心使命

task 元素定义智能体的主要目标和职责边界。它防止功能蔓延，并将智能体决策锚定在核心功能上。

示例：

Your primary mission is to resolve billing inquiries for enterprise
accounts by:
- Diagnosing billing discrepancies and system errors
- Providing step-by-step resolution guidance
- Escalating complex cases to appropriate specialists

如果缺少清晰任务定义，智能体就可能变成目的模糊的通用型助手，从而削弱性能和安全性。

Context：建立运行边界

context 为智能体提供关键情境意识，包括监管限制、访问控制、SLA 或组织价值。它编码硬规则和软预期。

示例：

You operate within a 24-hour SLA environment serving Fortune 500
clients. You must never request passwords or sensitive authentication
data. Your responses must comply with data privacy regulations. When
faced with ambiguity, prioritize customer satisfaction.

context 将智能体从通用工具转化为具备领域意识的行动者，使其能够停留在政策边界内，并适应真实世界约束。

反模式：缺失 context（范围歧义）

症状：智能体生成的输出在技术上正确，但在运营上不安全或不合规。

坏示例：

[CONTEXT] You serve enterprise clients in the financial sector.

为什么失败：没有监管范围、没有数据处理约束，也没有 SLA。一个处理金融数据的智能体，如果没有明确 GDPR 或 SOC 2 指引，可能记录 PII，提出不合规建议，或以让组织承担责任风险的方式处理敏感数据。

修正后：

[CONTEXT] You operate within a GDPR-compliant, SOC 2 Type II-certified environment serving EU-based enterprise clients in financial services. You must never store, repeat, or reference personally identifiable information in your responses. When uncertain whether an action is compliant, default to refusal and escalate to a human reviewer. You operate under a 4-hour SLA for Severity-1 issues.

context 不是可选背景；它是智能体的运行法律。

Format：确保结构化且可预测的输出

format 定义智能体应如何组织输出。在输出会被其他智能体或 API 消费，或回应清晰度影响用户理解的系统中，这一点尤其重要。

示例：

Structure all interactions as follows:
1. Acknowledge the customer's concern with empathy.
2. Provide solutions in numbered, actionable steps.
3. Include relevant case numbers and documentation references.
4. Offer clear escalation pathways.
5. End with a commitment to follow-up when appropriate.

一致的回应格式支持互操作性、自动化和可读性，而这些对于智能体链式调用或关键业务任务至关重要。

PTCF 为智能体大脑提供架构蓝图之后，下一个挑战是执行：如何在能力和认知复杂度各不相同的智能体之间规模化提示设计？下一节将探索高级提示模式，从逐步推理到智能任务分解，揭示如何让提示复杂度与智能体智能相匹配。

PTCF 提示模板

使用下面这个填空式脚手架来构造任意符合 PTCF 的系统提示：

[PERSONA] You are a [role/title] with [relevant expertise or experience]. Your communication style is [tone descriptor] and you approach problems [reasoning style].

[TASK] Your primary mission is to [core objective]. You are responsible for [specific responsibilities]. You must not [explicit boundaries].

[CONTEXT] You operate in [environment description]. Your users are [audience]. Relevant constraints include [regulatory, technical, or operational limits]. When instructions conflict, [conflict resolution rule].

[FORMAT] Structure all responses as [output structure]. Use [format specification: JSON / Markdown / numbered list / etc.]. Maximum response length: [token or word limit]. When uncertain, [fallback behavior].

设计会思考的智能体

随着智能体从反应式回应者演化为战略协作者，它们的内部推理机制也必须同步发展。仅用静态提示来指示智能体已经不够。我们必须架构化它们如何思考、规划和即兴应变。本节将探索如何通过高级提示模式，设计与自主智能体不断增长能力相匹配的认知脚手架。

这些模式并不是任意的。它们代表了智能体工程旅程中的自然演进：从基础输入/输出流，到能够分解目标、调整策略，甚至从反馈中学习的系统。作为提示词工程师，我们的工作不只是发布命令，而是将推理逻辑直接编码进智能体的运行结构中。

这些提示模式并不孤立存在；它们是我们与语言模型互动方式清晰演化路径的结果。要充分理解高级提示策略的角色和必要性，就必须理解我们是如何走到这里的。

从命令到认知

在最早使用 LLM 的阶段，提示被看作一种黑箱技术：简单指令进去，结果出来。随着 system/user 提示分离和 PTCF 等正式设计框架的引入，这个领域逐渐成熟。提示变成持久契约，而不是临时建议。它们开始定义智能体身份（persona）、使命（task）、运行边界（context）和沟通逻辑（format）。

现在，第三个前沿已经出现：cognitive prompting patterns，也就是塑造智能体如何随时间推理的认知提示模式。这些模式是嵌入提示中的具体策略，用于引导智能体内部思维过程，使其能够执行复杂推理、规划和问题解决。不同于规定智能体应该做什么的基础指令，认知提示模式影响它如何思考才能实现目标。例如，一种认知提示模式可能是要求智能体在给出最终答案之前逐步思考，或在面对含糊问题时考虑多个视角。这些模式有助于弥合高层人类目标与低层机器可执行行动之间的差距。它们对于释放复杂智能体的全部潜力至关重要。

例如，一种广泛使用的认知模式是 chain-of-thought（CoT）提示。假设你正在构建支持智能体，并问：“Why was my account suspended?”

CoT 风格提示可能引导智能体这样回应：

Let me first check the user's recent activity. Then, I'll look for any violations of the terms of service. Finally, I'll determine whether a suspension notice was issued.

这种逐步推理帮助智能体透明地追踪逻辑，提升可解释性和可靠性。

让提示策略与智能体能力对齐

就像软件架构师会根据系统复杂度选择设计模式一样，提示词工程师也必须调整策略，使其匹配智能体的认知成熟度。例如，一个简单反应式智能体可能只需要直接命令，而一个复杂学习型智能体则需要为复杂推理和自我纠错搭建脚手架的提示。智能体能力谱系这个概念，帮助我们根据自主性和推理深度对智能体进行分类，从简单回应者到反思型学习者。

来看这个谱系中的关键层级：

Level 1：反应式智能体
基于简单触发—回应逻辑运行，没有记忆或规划。提示必须明确且直接，类似命令行指令。

Level 2：工具使用型智能体
能够调用外部 API 或函数。提示不仅要指导它们做什么，也要指导如何使用工具以及何时使用。

Level 3：规划型智能体
这类智能体可以把抽象目标拆解为具体步骤。提示必须启动结构化分解，通常通过 “think step by step” 等短语实现。

Level 4：学习型智能体
在这一阶段，智能体可以评估反馈、反思表现并改进。提示成为元认知蓝图，引导智能体对自身推理过程进行推理。

图 3.2——随着智能体能力扩展提示复杂度

这个金字塔图说明了一个关键原则：提示复杂度必须随认知复杂度一起提升。当智能体能力上升，从反应式到学习型，提示策略的复杂程度也必须相应上升。左轴标记不断增加的认知深度；右轴标记对应需要更丰富提示策略。在底部，简单命令已经足够。在顶部，提示必须为反思性推理、记忆整合和行为适应搭建脚手架。

LangChain 和 CrewAI 等框架正是将这一原则操作化。LangChain 的 RunnableSequence 和 AgentExecutor 类为 Level 2 和 Level 3 智能体而设计，也就是需要结构化提示模板、工具注册表和输出解析器的工具调用型与规划型智能体。CrewAI 则通过其 Agent、Task 和 Crew 抽象，将这一能力扩展到 Level 3 和 Level 4 领域，支持多智能体编排，其中每个智能体的提示会自动限定到其被分配的角色和能力层级。完整文档可见 docs.langchain.com 和 docs.crewai.com，请查看当前 API 参考以获得版本特定用法。

提示词工程中一个关键方面，尤其对于规划型智能体而言，是让它们能够分解复杂目标。这引出了一个基础认知模式：任务分解的艺术。

从意图到执行：任务分解的艺术

智能体设计中一个最持久的挑战，是目标歧义。用户经常用宽泛语言表达：

Plan my business trip
Help me launch a product
Summarize this research

对人类来说，这些请求很明显。对智能体来说，它们是不充分指定的。plan 是什么意思？存在哪些约束？涉及哪些步骤？

这就是任务分解变得必要的地方。

通过设计能够触发内部规划例程的提示，智能体可以将含糊命令转化为结构化、可执行工作流。这种能力不是自然涌现的；它必须显式嵌入智能体系统提示中，尤其是 PTCF 框架中的 task 和 format 组件。

示例：

在 task 组件中：

Break down vague user requests into sequential steps before taking action

在 format 组件中：

Present your plan as a numbered list of sub-tasks, ordered by dependency

这些不只是风格偏好；它们是在智能体认知架构中编码规划反射。

图 3.3——从模糊意图到结构化行动

图 3.3 展示了一个智能体在面对模糊目标 “Plan my upcoming business trip to Tokyo” 时，如何避免立即执行。相反，它先生成结构化计划：

1. 确认旅行日期和预算。
2. 搜索航班。
3. 检查签证要求。
4. 提出行程。

每一步都按逻辑顺序排列，并在上下文上依赖前一步。通过建模这种分解，智能体表现得更像一位胜任的执行助理，而不是执行脚本的机器人。

这个示例强调了一个关键洞察：当系统提示指定分解行为，并相应格式化输出时，智能体可以具备前瞻性，而不只是反应性。

提示词工程遇上认知架构

本节介绍的模式，也就是能力对齐、分解和结构化规划，不是孤立技巧；它们是 PTCF 框架的直接扩展。

下表将这种映射具体化。本章介绍的每一种认知提示模式，都能在 PTCF 框架中找到直接位置；它不是框架之外的新增内容，而是对四个组件之一的展开。

Pattern	PTCF Element	Use Case	Complexity
Capability alignment	Format	让提示冗长程度匹配智能体层级	Low
Task decomposition	Task	将含糊目标拆分为子任务	Medium
Chain-of-thought	Format	连续逐步输出	Medium
Tree-of-thought	Task + context	带综合的并行推理分支	High
Few-shot learning	Context	通过嵌入示例引导行为	Low–medium
Role-based persona	Persona	身份与权限范围设定	Low

表 3.1——认知模式到 PTCF 组件映射

请注意：

• persona 影响智能体如何解释歧义；
• task 定义规划和分析需求；
• context 决定哪些工具、约束或依赖是相关的；
• format 强制结构化思考和输出。

这些高级提示技术代表了提示词工程的下一次演进：不仅定义智能体是什么或做什么，也定义它如何思考。

生产级智能体需要在提示架构中嵌入明确的失败恢复和状态管理策略。LangChain 的 RunnableWithFallbacks 允许一条链指定一个或多个 fallback runnables，当主链抛出异常时激活，从而实现优雅降级而不是静默失败，请查看 docs.langchain.com 当前 API 参考。对于长交互中的状态管理，LangChain 的 entity memory 模块和 CrewAI 的内置 memory 抽象，都提供了跨轮次持久化关键事实的机制，同时避免膨胀上下文窗口。提示词工程师的角色，是定义智能体应该记住什么，这会编码在 PTCF 的 context 组件中，保留多久，以及何时丢弃过时状态，把记忆视为一等架构关注点，而不是事后补充。

随着智能体能力增强，另一个挑战出现了：它们如何从有限示例中学习，并有效泛化到新场景？下一节将探索 few-shot learning，也就是少样本学习。这是一种强大策略，允许智能体通过少量直接嵌入上下文窗口的示例获得新技能和行为模式。

通过示例进行教学：少样本学习作为智能体适应性的催化剂

随着我们推进智能体设计边界，一个关键问题出现了：智能体如何在不重新训练的情况下快速学习新任务，同时仍然与其设计好的 persona、目的和运行约束保持一致？答案在于一种变革性技术：少样本学习。

少样本学习是将战略性示例直接嵌入提示中，用于引导智能体推理和输出的实践。我们不是在成千上万条标注样本上微调模型，而是通过类比来教学：展示少数精心构造的案例，说明期望行为。这样，我们把提示转化为动态教学环境，使其能够快速适应新的工作流、分类方式或决策规则。

当少样本学习与 PTCF 框架结合使用时，尤其强大。少样本示例天然适合放入系统提示的 context 组件中，在那里它们作为实时示范，强化智能体应如何解释模糊输入并生成结构化输出，同时不偏离角色（persona）、不漂移出使命（task），也不违反格式标准（format）。

起源与演化：从预训练到提示

少样本学习随着 GPT-3 发布而受到关注，GPT-3 显示出 LLM 仅从少数示例中就能进行显著泛化。在此之前，定制通常需要微调，也就是在较小的任务特定数据集上重新训练预训练模型，以适应新领域或新目标。这个过程昂贵、耗时且静态。少样本学习提供了一种更敏捷的推理时解决方案：无需改变模型权重，只需精心设计提示。

这就是我们今天所称的 in-context learning，也就是上下文学习的起源。它重塑了从客户服务到法律推理和技术分诊的一切。少样本学习不是 RAG 的替代品，而是在以下场景中的轻量替代或补充：

• 上下文狭窄且自包含；
• 延迟或成本不允许外部搜索；
• 模式可以通过少量示例表达。

RAG 适合需要长篇知识检索的场景，例如根据法律文档回答技术问题，总结政策手册，或基于客户历史生成报告。

少样本学习则适合从直接示例中学习推理模式的场景，例如分类邮件语气，根据紧急程度分诊支持工单，或生成遵循特定格式的摘要。

少样本学习中多少示例才够？

few 这个词是字面意义上的“少”。在实践中，不同提示策略可以使用以下数量示例：

• Zero-shot 零样本：没有示例；模型只依赖指令。
• One-shot 单样本：一个示例。
• Few-shot 少样本：通常 2 到 5 个示例；有时根据任务复杂度和上下文窗口大小，最多可达 10 个。

示例的质量和结构远比数量重要。超过某个点后，增加示例会带来递减收益，甚至可能压垮模型注意力范围。

我们在解决什么问题？

少样本学习回应了现代 AI 部署中的三个核心挑战：

无需重新训练的定制化：组织需要智能体快速适应新用例，而不需要耗时的数据标注或模型更新。

行为可靠性：嵌入示例可以通过强化与业务或运营逻辑一致的回应模式，提高一致性并减少幻觉。

可访问性和速度：非工程师也可以创建有效少样本提示，使 AI 定制在团队间更加民主化，也更具迭代性。

下面我们考察少样本学习如何在 PTCF 框架中操作化细致推理。

实践演练：用示例教智能体进行工单路由

下面的示例说明，支持智能体如何在完全由嵌入上下文的示例引导下，通过分析意图、语气、紧急性和内容来分类并路由技术工单。

Context：嵌入式少样本示例

下面的系统提示展示了嵌入示例如何引导智能体分类决策：

You are a technical support ticket processor. Your classifications and
routing decisions directly impact resolution times and customer
satisfaction. Use the following examples to guide your decisions.

Example 1

- Input: "I am so happy with this service! Just wanted to say thanks."
- Analysis: Positive sentiment, no action needed
- Classification: {"Urgency": "Low", "Category": "Feedback", "Action": "None"}

Example 2

- Input: "My bill might be incorrect, can someone look at it?"
- Analysis: Polite query about billing; non-urgent
- Classification: {"Urgency": "Medium", "Category": "Billing", "Action": "Route to Billing Dept."}

Example 3

- Input: "I can't log in, and I have a deadline in an hour!"
- Analysis: Account lockout with high urgency
- Classification: {"Urgency": "High", "Category": "Account Access", "Action": "Initiate Password Reset Protocol"}

Example 4

- Input: "My entire system is down and I'm losing money every minute!"
- Analysis: Total outage with financial impact
- Classification: {"Urgency": "Critical", "Category": "Outage", "Action": "Escalate to Tier-2 Engineering"}

为什么有效：从模板到认知迁移

这些示例不只是提供指令，它们塑造认知。将它们放入系统提示的 context 部分后，会发生以下情况：

• persona 保持完整，智能体仍然像支持处理器那样“行动”；
• task，也就是分类和路由，被具体化；
• format，也就是基于 JSON 的输出，被每个示例强化。

智能体不只是模仿；它会泛化。它学会围绕意图推理，检测紧急性，并将行动与结果对齐。这将静态指令转化为情境判断。

尽管少样本学习很强大，但它并不适合所有场景。它最适合以下情况：

• 问题领域有边界且模式丰富；
• 示例可以简洁表达；
• 上下文窗口足够大，可以纳入足够细节。

它在以下情况下表现较弱：

• 任务需要检索外部文档，这更适合 RAG；
• 边界案例很多，示例变得过于碎片化；
• 推理涉及多跳逻辑或长链式思考，这需要结构化提示，下一节将探索。

下表提供了直接对比，用于指导在少样本学习和 RAG 之间作出选择：

Dimension	Few-Shot Learning	RAG
Data freshness	静态，嵌入提示中	动态，检索得到
Context window cost	高，示例内联	较低，只注入 chunks
Setup complexity	低，不需要基础设施	中到高，需要向量数据库
Best fit	模式丰富、有边界的任务	大型/变化中的文档语料
PTCF component	Context	Context
Key failure mode	上下文溢出	检索幻觉

表 3.2——少样本学习与 RAG：决策指南

通往预测性智能的入口？

少样本提示不只是复制输出；它会模拟推理。在某些领域中，它甚至可以成为轻量预测分析的入口。例如：

• Marketing 营销：从邮件中分类情绪趋势。
• Finance 金融：对文本报告中的风险等级进行分类。
• Operations 运营：根据可能升级路径分诊事故。

然而，不同于训练好的统计模型，它缺乏概率基础，无法执行定量预测。当推理是基于模式时，它可以辅助类似预测的任务；但当需要数值精度或跨大规模分布泛化时，它不适用。例如，少样本学习可以帮助智能体根据少量示例中观察到的关键词和情绪模式，预测某封客户邮件是否表明高流失可能性。但它不适合定量预测下一季度百万用户中的具体客户流失比例，因为那需要统计训练模型和大规模数据分析。

少样本学习让智能体表现出类似记忆的行为。但要更进一步，构建能够外化、结构化并评估自身思考的智能体，我们需要更强大的方法。下一节将探索结构化推理，也就是提示本身成为逻辑脚手架。我们将深入介绍两种变革性技术：CoT 和 tree-of-thought（ToT）提示。

让推理可见：Chain-of-thought 与 Tree-of-thought

前面介绍的模式帮助我们定义智能体的宪法，并教它技能，但还有一个根本挑战：信任与透明性。早期 LLM 经常被批评为“黑箱”；它们会产生答案，但内部推理隐藏不可见，因此无法调试错误，也无法在复杂任务上信任其结论。要让智能体从不透明神谕变成透明认知伙伴，我们需要让它们的思考过程可见且可审计。

解决方案来自 AI 研究中的一个关键洞察：提示不仅可以塑造最终输出，也可以塑造整个推理过程。这推动了结构化推理方法的发展。第一个重大突破是 CoT 提示，它指示智能体在给出答案之前逐步推理。这个简单技术显著提升了逻辑任务表现，并且关键的是，它创造了透明的逻辑轨迹。之后，研究人员提出 ToT 提示，作为更高级方法，使智能体能够并行探索多条推理路径，克服单一线性思维过程的局限。

图 3.4——线性推理模型与并行推理模型对比

如图 3.4 所示，这两个范式代表了不同的问题解决模型。

左侧展示 CoT，它是一种线性、顺序流，非常适合那些受益于有条理、逐步审议的问题。例如，CoT 提示可以通过以下方式引导智能体调试软件错误：第一，检查日志文件中的错误；第二，验证网络连接；第三，确认数据库访问；最后，报告根因。右侧展示 ToT，它代表发散式方法，在综合为最终方案前，并行探索多条推理路径，适合没有单一正确路径的复杂挑战。例如，ToT 提示可以要求智能体为新产品头脑风暴三种不同营销策略，评估每种策略的优缺点，然后选择最优方案并解释选择理由。这类似一个团队在收敛到解决方案之前探索多个选项。这两种强大的推理模式，都由 PTCF 框架支持，通常通过在系统提示的 format 组件中指定所需推理风格来实现。

表 3.3 中的决策指南，可以帮助实践者根据问题特征在两者之间选择：

Dimension	Chain-of-Thought（CoT）	Tree-of-Thought（ToT）
Problem structure	顺序、线性	多路径、探索式
Output form	单一推理答案	综合共识
Compute cost	低，单链	高，并行分支
Key failure mode	过早承诺	分支爆炸
PTCF home	Format	Task + context
Example use case	根因诊断	发布策略设计

表 3.3——CoT 与 ToT：何时使用哪一个

这张图清楚说明了一件事：没有万能提示。高级智能体需要建立在架构之上的高级引导，而不是即兴发挥。

接下来的小节中，我们将探索提示词工程中两种最有效的结构化推理技术：CoT 和 ToT 提示。每一种都为引导智能体认知和问题解决提供不同方法。

Chain-of-thought：有条理的分析师

CoT 提示引导智能体经历线性、逐步的分析过程。它最适合那些拥有清晰、顺序解决路径的问题，例如执行算术计算、完成一系列指令，或对文档进行逻辑总结。CoT 在需要有条理推理的任务中表现突出。

不过，对于简单事实问题，例如 “What is the capital of Canada?”，使用逐步方法既不必要，也低效，因此在这类情况下 CoT 提示过度了。

为说明这一点，考虑一个智能体被要求为新的 AI 教育应用制定发布策略。CoT 风格提示可能引导智能体一步一步定义受众、识别核心功能、选择定价模式并概述营销计划。在这种场景中，智能体像一个按清单工作的单一战略顾问。如图 3.4 左侧所示，这个过程逻辑清晰且结构化，但其主要弱点是刚性。如果早期假设有误，例如目标市场选错了，整个策略可能建立在错误基础上，并且没有机制自我纠正。

Tree-of-thought：虚拟战略团队

ToT 智能体进一步推进了这一点。它能够创建不止一位虚拟专家，从多个视角同时分析问题。这些虚拟专家随后可以相互讨论和辩论复杂问题，以得出最稳健的解决方案。这种方法对需要多视角分析的模糊问题非常有效，模拟了人类专家团队头脑风暴解决方案的方式。

ToT 智能体将问题转化为目标，并启动多个并行思维过程，就像项目经理指挥虚拟专家团队一样。

目标是为一款新的 AI 教育应用制定综合发布策略。

下面的演练通过这个产品发布场景，追踪 ToT 流程的每个阶段：

分解（创建虚拟专家） ：智能体首先拆解问题，并将不同方面分配给虚拟专家：

• 分支 A（虚拟市场分析师） ：探索三个不同目标市场的可行性：高中生、大学生和企业培训部门。
• 分支 B（虚拟财务规划师） ：辩论最优商业模式，比较一次性购买与分层订阅。
• 分支 C（虚拟营销专家） ：头脑风暴认知度推广活动，包括 influencer marketing、LinkedIn 付费广告和内容营销。

模拟讨论（评估与剪枝） ：虚拟专家随后讨论各自发现：

市场分析师提出结论：大学生市场在需求和支付意愿之间提供了最佳平衡，因为高中市场过于饱和，而企业市场销售周期较长。

听到这一点后，财务规划师认为，订阅模式更适合从大学生受众中获得经常性收入。因此，一次性购买方案被剪枝。

营销专家基于这个共同结论调整计划，放弃 LinkedIn 策略，将精力集中在更适合触达大学生的 influencer 和内容营销活动上。

综合（集成方案） ：智能体将讨论中获胜的论点整合为一个单一、连贯的策略：以大学生为目标受众，采用 freemium 订阅模式，并通过 influencer outreach 与内容营销组合进行推广。

为了使这一过程具体化，下面的 LangChain 实现展示了前文描述的 ToT 虚拟战略团队。代码使用 LangChain v0.1.x 语法，并使用管道操作符 | 进行 chain composition：

# LangChain v0.1.x / langchain-core 0.1.x
# pip install langchain-core langchain-openai

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.7)

# — Branch prompts (three virtual experts) —
market_prompt = ChatPromptTemplate.from_template(
"You are a Virtual Market Analyst. "
"Evaluate the best target market for a new AI-powered educational app. "
"Consider: high school students, university students, and working professionals. "
"Provide a concise recommendation with supporting rationale."
)

finance_prompt = ChatPromptTemplate.from_template(
"You are a Virtual Financial Planner. "
"Given this market analysis: {market} "
"Recommend the optimal business model: one-time purchase, subscription, or freemium. "
"Justify based on the recommended market segment."
)

marketing_prompt = ChatPromptTemplate.from_template(
"You are a Virtual Marketing Specialist. "
"Given market analysis: {market} and financial model: {finance} "
"Design a focused awareness campaign for the target segment. "
"Specify channels, messaging, and one measurable KPI."
)

synthesis_prompt = ChatPromptTemplate.from_template(
"You are a Strategic Synthesis Agent. "
"Integrate the following expert analyses into a coherent launch strategy: "
"Market Analysis: {market} "
"Financial Model: {finance} "
"Marketing Plan: {marketing} "
"Output a structured recommendation with three sections: "
"Target Segment, Revenue Model, and Go-to-Market Plan."
)

# — Build chains using the pipe operator —
market_chain = market_prompt | llm
finance_chain = finance_prompt | llm
marketing_chain = marketing_prompt | llm
synthesis_chain = synthesis_prompt | llm

# — Execute branches —
market_result = market_chain.invoke({})

# NOTE: target_market is derived from market_result.content in production;
# hardcoded here as "university students" to isolate the synthesis demonstration.
target_market = "university students"

finance_result = finance_chain.invoke({"market": market_result.content})
marketing_result = marketing_chain.invoke({
"market": market_result.content,
"finance": finance_result.content
})

# — Synthesize: keyword args must match {market}, {finance}, {marketing} placeholders —
final_strategy = synthesis_chain.invoke({
"market": market_result.content,
"finance": finance_result.content,
"marketing": marketing_result.content
})

print(final_strategy.content)

上述代码实现了三阶段 ToT 过程。在分解阶段，market_prompt、finance_prompt 和 marketing_prompt 分别实例化一个虚拟专家，对应前文演练中的分支 A、B 和 C。每次调用 ChatPromptTemplate.from_template 都使用 PTCF 原则编码专家 persona 和任务范围。

在模拟讨论阶段，顺序调用模式建模了评估和剪枝：market_result 输入 finance_chain.invoke()，后者输出再输入 marketing_chain.invoke()。每个专家的结论都会影响下一个专家，复制了前面描述的迭代优化过程。需要注意的是，target_market 被硬编码为 “university students”，只是为了隔离综合演示；在生产中，这个值会从 market_result.content 中派生出来。

在综合阶段，synthesis_chain 通过与模板占位符匹配的关键字参数 market、finance、marketing 接收三个专家输出。综合提示指示智能体将这些分析整合成统一建议，并包含三个定义好的部分：Target Segment、Revenue Model 和 Go-to-Market Plan。整个代码中，管道操作符 | 将每个提示与 LLM 组合成一个可运行链，使实现保持声明式，并使每个专家的逻辑都可以独立测试。

虽然 ToT 提示使单个智能体能够跨多个视角进行推理，但下一个前沿在于让多个智能体协作，每个智能体都带来专门角色和能力。要从孤立智能走向协调系统，我们不仅要设计内部认知，还要设计治理智能体间通信的协议。

架构化协作：提示驱动的通信协议

在建立了单个智能体的 PTCF 蓝图之后，本节将同样的宪法性原则向外扩展，从单个智能体扩展到多个智能体组成的协调系统。这不是本章末尾引入的新话题，而是 PTCF 概念的逻辑结论：治理一个智能体行为的 persona、task、context 和 format 纪律，会自然扩展到治理智能体如何彼此通信。AI 的真正潜力并不来自单一、庞大的模型，而是来自智能体社会：各个专门个体通过结构化协作组合专业能力。从孤立问题解决者转向集体智能系统，是一次重要架构跃迁。它要求我们不仅设计智能体的内部宪法，也要建立智能体互动的“道路规则”。为了防止混乱并确保富有成效的协作，我们需要共享语言和清晰规则，也就是通信协议。

正如 PTCF 框架为单个智能体提供宪法性蓝图，它也为构建多智能体协议提供了理想基础。通过扩展这些原则，我们可以定义一个稳健系统，治理智能体如何识别自身、声明目的、共享上下文并组织消息结构。PTCF 框架中的每个组件都直接映射到智能体间通信的一项关键需求：

Persona 建立智能体独特且可验证的身份，例如 agent_alpha，也就是“信用风险分析师”，以及它在网络中的角色。它回答两个基础问题：“谁在说话？”以及“它有什么权限？”

Task 阐明一条消息的具体目的或意图。它是在请求数据、发出警报，还是提供分析更新？这通常会被捕捉在 message_type 字段中。

Context 提供连贯对话所必需的共享情境意识。它包括关键元数据，例如时间戳、对先前消息的引用和优先级，确保所有通信都扎根于共享现实中。

Format 定义所有智能体同意使用的通用语法。通过强制标准化结构，通常是 JSON 等机器可读 schema，我们创造一种 lingua franca，也就是通用语，消除歧义，并确保一个智能体的输出可以无缝作为另一个智能体的输入。

为了使其具体化，我们为一个金融风险评估网络设计通信协议，其中专门智能体必须协作。为了确保每条消息都能被可靠路由、处理和审计，我们可以定义一个标准 JSON 格式。这个结构不只是数据容器；它是我们通信规则的具体体现：

// Communication Protocol Example
{
  "sender_id": "agent_alpha",
  "recipient_id": "agent_beta",
  "message_type": "risk_assessment_update",
  "timestamp": "ISO_8601_format",
  "confidence_score": 0.85,
  "data_payload": {
    "risk_category": "credit",
    "assessment_summary": "Credit risk remains low based on Q4 data.",
    "key_factors": ["stable_revenue", "low_debt_ratio"],
    "recommendations": ["maintain_current_rating"]
  },
  "context_references": ["previous_analysis_id_123"],
  "requires_response": false,
  "priority_level": "medium"
}

这种标准化格式确保每次通信都携带路由和审计所需的元数据，同时交付协作决策所需的实质内容。为了看到这个协议如何实现无缝工作流，图 3.5 可视化展示了金融风险网络如何运行。

图 3.5——多智能体通信架构

如图所示，结构化通信协议充当智能体团队的中枢神经系统。在这里，agent_alpha 作为信用风险专家，发送一条更新。它的消息不是被发送到虚空中，而是按照约定 JSON 格式组织起来。这条标准化消息充当通用翻译器，使 agent_beta，即市场风险专家，能够无歧义地解析信息，理解是谁发送的、目的是什么，以及关键发现是什么。该架构确保每个智能体都能在其专业领域内运行，同时为更大的综合分析贡献洞察。这个建立在 PTCF 原则之上的模型，正是把一组个体专家转化为一个连贯、智能集体的关键。

下面三个案例研究说明 PTCF 框架如何在代表性生产语境中运行。每个案例遵循一致模板：问题、PTCF 配置、结果和关键启示，以便使设计决策显性化且可迁移。结果指标是实践者报告改进类型的示意；具体数值会因部署环境、模型和基线而异。

案例研究 1：SaaS 客户支持分诊智能体

问题：一家 B2B SaaS 公司的支持团队将超过 40% 的客服时间用于手动分类和路由进入的工单。高严重等级问题有时会被延迟处理，因为提示中没有结构化升级逻辑。

PTCF 配置：

• Persona 将智能体定义为 Level-2 技术支持分诊专家，并明确拥有分配严重等级标签的权限。
• Task 指定三步分诊序列：分类、严重性评分和路由。
• Context 嵌入公司 SLA 阈值，Severity-1：1 小时，Severity-2：4 小时，Severity-3：24 小时，以及升级联系人。
• Format 强制结构化 JSON 输出，包含 ticket_id、category、severity、assigned_queue 和 suggested_action 字段。

结果：在团队试点中，人工分诊时间约减少 60–70%，这是示意性结果，具体取决于工单数量和复杂度。Severity-1 工单在评估期内始终被路由到 SLA 窗口内。消费 JSON 输出的下游智能体无需进行格式协商。

关键启示：将 SLA 阈值直接嵌入 context 组件，可以消除对单独规则引擎的需求。format 组件中的 JSON 契约使智能体可组合；它的输出无需转换层即可成为路由智能体的输入。

案例研究 2：金融合规审查智能体

问题：一家金融服务公司需要在人工审查之前，对客户沟通进行预筛查，以识别潜在监管政策违规。早期提示迭代如果缺乏显式行为约束，偶尔会生成看似合理但不合规的指导。

PTCF 配置：

• Persona 将智能体设定为“合规预筛查专家”，无权提供财务建议，只能标记潜在政策引用供人工审查。
• Task 定义两遍流程：首先识别政策相关语言，然后将风险等级分类为 Low、Medium 或 High。
• Context 嵌入适用监管类别，例如 MiFID II 或 FCA COBS，明确禁令，例如不得提供建议或预测，并为高风险分类设定强制人工升级规则。
• Format 生成结构化审查报告，包括 risk_level 字段、flagged_passages 数组和 reasoning 字段。

结果：在团队评估集中，智能体成功预筛查了沟通内容，人工审查者确认在代表性样本中，智能体风险分类与其判断高度一致，这是示意性结果；精确准确率取决于模型、司法管辖区和语料。关键是，在测试期间，没有任何高风险项在未人工升级的情况下被路由。

关键启示：在受监管领域，context 组件充当合规护栏，而不仅仅是背景信息。明确禁令和强制升级规则应属于 context，而不是从 persona 中推断。format 中的 reasoning 字段提供了合规团队所需的审计轨迹。

案例研究 3：自动化代码审查智能体

问题：一个软件工程团队希望自动化 pull request 的第一轮代码审查，重点关注风格指南违规、安全反模式和测试覆盖缺口。最初尝试生成的审查要么过于简短，缺乏上下文，要么过于冗长，阻碍开发工作流。

PTCF 配置：

• Persona 将智能体定义为资深软件工程师和代码审查者，采用建设性、非阻断式沟通风格。
• Task 指定三类审查范围：1）风格指南合规；2）OWASP Top 10 安全模式；3）测试覆盖缺口，并明确只标记 Critical 和 Major 问题，不提出纯装饰性建议。
• Context 嵌入团队风格指南 URL、OWASP 参考、语言版本 Python 3.11，以及一条硬规则：绝不因为 Minor 问题阻断 pull request。
• Format 生成 Markdown 审查报告，包含 findings 表格，字段包括 Category、Severity、Line Reference 和 Recommendation，以及 overall_verdict 字段，取值 Approve 或 Request Changes。

结果：在团队内部评估中，资深工程师估计，智能体在代表性 pull request 上正确识别了大多数他们自己也会标记的 Critical 和 Major 问题，这是示意性结果；精度会随代码库、语言版本和模型不同而变化。由于自动审查输出消除了 Minor 问题噪声，开发者工作流摩擦下降。

关键启示：task 组件中的显式范围边界，即只关注 Critical 和 Major，是最有影响的设计决策。它把智能体从嘈杂审查者转化为可信的第一轮过滤器。format 中的 overall_verdict 字段使智能体能够无需额外工具集成，就嵌入既有 pull request 工作流，展示了结构化输出如何以零集成成本实现可组合性。

这些案例研究确认了一个一致模式：PTCF 提示越精确地编码 persona、任务边界、上下文约束和输出格式，智能体行为就越接近生产要求。自然的下一问题是：随着提示随时间演化，我们如何维持这种对齐？

迭代与评估提示

打造提示很少是一次性练习。即使结构良好的 PTCF 提示，也需要随着真实使用暴露出预期行为和实际行为之间的差距而进行调优。有纪律的迭代流程，可以将提示词工程从直觉性手艺转化为可重复、证据驱动的实践，使质量可衡量，并使回归问题在到达生产之前可检测。

实践中有两种评估策略特别有效：A/B 测试和回归测试。

A/B 比较用同一输入集运行两个提示变体，并基于定义好的指标比较输出：准确率、格式遵循、回应长度或任务完成率。这可以隔离单一变更的影响，避免仅凭主观印象判断修订的常见错误。

回归测试维护一组规范输入及其预期输出参考集。任何提示修订在进入生产之前，都必须通过完整测试套件，不能破坏任何之前已经通过的案例。这两种策略结合起来，可以确保改进是真实的，并且某一方面的收益不会在其他地方引入失败。

以案例研究 1 中的支持分诊智能体为例。为了测试更具指令性的 persona 是否能提高路由准确性，你创建两个提示变体：Variant A 保留原始 persona，“You are a technical support ticket processor”；Variant B 采用更坚定的框定，“You are a senior escalation analyst who prioritizes speed-to-resolution”。两个变体共享完全相同的 task、context 和 format 组件。随后，你用一组保留的 50 条预标注工单运行两者，并比较分类准确率、紧急性一致性和路由匹配率。如果 Variant B 将准确率从 82% 提高到 89%，且没有增加错误升级，那么该变化得到验证。

再假设你优化案例研究 3 中代码审查智能体的 task 组件，排除 Minor 严重等级问题，将审查者注意力聚焦在 Critical 和 Major 发现上。在部署这一变更之前，你用包含 20 个代码样本的规范套件运行修订提示，这些样本都有已知预期输出。通过/失败门槛检查两个条件：所有之前检测到的 Critical 和 Major 问题仍必须出现，并且不能引入任何高于 Minor 的新误报。如果套件返回 20/20 通过，修订可进入生产。如果哪怕一个 Critical 发现消失，该变更就会被拒绝，并重新修订 task 表述。

当提示失败或表现不足时，下面四步循环提供了一条系统性诊断和解决路径：

Baseline 建立基线：捕获当前提示版本及其在测试套件上的性能指标。这会建立所有变更都要对照的 ground truth，也就是基准事实。

Evaluate 评估：用代表性输入运行失败或表现不足的提示。分类失败模式：智能体是在误识别 persona，误解 task，缺少必要 context，还是产生了违反 format 约束的输出？

Identify 识别：隔离导致失败的具体 PTCF 组件。对根因作出最小、有针对性的变更，例如收紧 persona 权限范围，向 task 添加约束条款，或向 context 中插入缺失边界条件。

Revise and version 修订并版本化：应用变更，为修订提示标记版本标识，例如 v1.2.0，并运行完整回归套件。只有当修订解决目标失败且没有引入新失败时，才接受它。保存提示及其评估结果，把提示历史当作源代码，而不是草稿纸。

跨多次迭代重复这一循环，会让提示逐渐收敛到可靠行为。那些把提示词工程当作软件工程学科来处理的团队，也就是采用版本化产物、测试套件和文档化变更理由的团队，会持续优于依赖临时编辑和人工审查的团队。

本章介绍的技术，为构建智能智能体行为提供了工程基础：PTCF 结构化提示、认知提示模式、少样本学习和多智能体协议。第 4 章将在此基础上讨论当这些智能体进入生产环境时会发生什么：在真实负载下扩展智能体系统，实施安全和隐私保护，进行故障与恢复设计，并处理规模化部署伴随的治理和负责任 AI 义务。

小结

本章探讨了智能体提示的艺术，展示了如何从编写简单指令，转向架构化完整认知框架。我们确立了这样一点：在现代 agentic systems 中，提示充当宪法，塑造智能体身份、推理和行为。PTCF 框架，即 persona、task、context 和 format，为这一过程提供了有纪律、系统化的基础，使开发者能够构建可靠、可预测并与人类目标对齐的智能体。

通过利用 PTCF 蓝图，我们展示了如何实现面向任务分解、少样本学习，以及使用 CoT 和 ToT 提示进行结构化推理的高级模式。此外，我们还详细说明了这些相同原则如何扩展到多智能体系统的架构中，在那里，标准化通信协议支持无缝协作和集体智能的综合。最终，这种有纪律的方法将提示词工程从临时手艺转化为成熟工程学科，确保随着 AI 系统复杂度增长，它们仍然保持透明、可信且有效。

当我们从构建智能体转向在真实世界场景中部署它们时，关注重点会转向这些系统运营化的关键方面。下一章将深入探讨智能体部署的复杂性，覆盖智能体系统扩展、稳健安全和隐私措施实施，以及负责任 AI 开发和治理中的关键考量。