AI Agent 不严格按照字面指令执行的根本原因在于其核心决策机制——大语言模型（LLM）是基于概率生成文本的，其输出具有不确定性，且容易受到上下文、内在偏见和“幻觉”的影响 。因此，在设计任务时引入“强制检查点”是Harness Engineering（驾驭工程）中的关键实践，旨在通过系统性的外部约束来引导、验证和纠正Agent的行为，确保其输出符合预设的SOP（标准操作流程）和业务逻辑 。

一、Agent为何不按字面执行：三大核心原因

二、“强制检查点”的作用与实现机制

“强制检查点”是Harness Engineering中“约束、告知、验证与纠正”四大职能的具体体现，尤其侧重于验证与纠正 。其核心作用是通过在任务流的关键节点设立不可绕过的验证环节，将自然语言描述的SOP转化为机器可严格执行的硬性约束。

1. 核心作用：

• 确保SOP遵循率：通过显式定义步骤编号和验收标准，将SOP从模糊的自然语言描述转化为结构化的、可检查的指令序列。实践表明，采用类似SP-5模板的结构化Prompt，能将SOP遵循率从极低的水平（如12.7%）大幅提升至超过90% 。
• 抑制幻觉与越界：在输出最终结果前，强制Agent根据检查点清单进行自检，可以提前发现并纠正字段缺失、格式错误、内容超纲等问题。
• 管理任务熵：在长周期或复杂任务中，检查点作为“熵管理”的手段，定期将Agent的认知和行为拉回正轨，防止其因信息累积或错误累积而失控 。

2. 实现机制与技术示例：

强制检查点通常通过 “系统提示词设计” 与 “程序化验证框架” 相结合来实现。

• 系统提示词中定义检查点：在Prompt中明确列出必须执行的步骤和每个步骤的产出标准。以下是基于SP-5模板的简化示例：

  # 系统提示词 (System Prompt) 片段
  system_prompt = """
  你是一个订单处理Agent。你必须严格按以下步骤执行，并在每个步骤完成后输出指定格式的检查结果：
  
  **强制操作流程 (SOP):**
  1.  **步骤一：验证订单号**
      - 输入：用户提供的订单字符串。
      - 操作：检查订单号是否符合格式“ORD-YYYYMMDD-XXXXX”。
      - 输出检查点：{"step": 1, "status": "pass/fail", "detail": "..."}
  
  2.  **步骤二：查询订单状态**
      - 输入：已验证的订单号。
      - 操作：调用`get_order_status`工具查询。
      - 输出检查点：{"step": 2, "status": "pass/fail", "detail": "状态信息或错误原因"}
  
  3.  **步骤三：执行后续操作**
      - 输入：订单状态。
      - 操作：若状态为“待发货”，则调用`schedule_shipment`；否则，告知用户当前状态。
      - 输出检查点：{"step": 3, "status": "pass/fail", "detail": "执行的操作结果"}
  
  **输出规则：**
  - 你必须依次执行以上所有步骤。
  - 每个步骤完成后，立即生成对应的JSON检查点。
  - 只有所有步骤的`status`均为“pass”，才可输出最终给用户的自然语言回复。
  """
  

• 程序化验证与拦截：后端应用程序解析Agent返回的每个检查点JSON，如果任何一步status为“fail”，则立即终止流程或要求Agent重试，而不是继续执行后续可能错误的操作。这构成了一个简单的Generator-Evaluator架构 。

• 利用LLM原生能力强化约束：在调用大模型API时，使用response_format参数强制要求输出为JSON，并结合JSON Schema或Pydantic模型来精确约束检查点输出的数据结构，从语法层面杜绝格式错误 。

  from openai import OpenAI
  from pydantic import BaseModel
  from typing import Literal
  
  # 使用Pydantic定义严格的检查点数据结构
  class Checkpoint(BaseModel):
      step: int
      status: Literal["pass", "fail"]
      detail: str
  
  # 在API调用中指定响应格式为JSON，并传入由Pydantic模型生成的schema
  client = OpenAI()
  response = client.chat.completions.create(
      model="gpt-4",
      messages=[{"role": "system", "content": system_prompt},
                {"role": "user", "content": "我的订单号是ORD-20231015-12345。"}],
      response_format={"type": "json_object"}, # 强制JSON输出
      # 在实际复杂场景下，可将JSON Schema作为工具调用的一部分或单独提示注入
  )
  # 解析后可使用Pydantic进行验证
  try:
      checkpoint_data = Checkpoint.model_validate_json(response.choices[0].message.content)
      if checkpoint_data.status == "fail":
          raise ValueError(f"检查点失败: {checkpoint_data.detail}")
  except Exception as e:
      # 处理验证失败或逻辑失败
      print(f"检查点验证错误: {e}")
  

三、总结：从Prompt Engineering到Harness Engineering

“强制检查点”的引入，标志着AI应用开发从单纯的Prompt Engineering（依赖模型理解模糊指令）向Harness Engineering的范式转变 。后者认识到，完全依赖LLM的“自觉性”是不可靠的，必须通过外部架构约束来构建一个可靠的执行环境（Harness）。这个环境通过上下文工程提供精准信息，通过检查点进行持续验证，通过程序化逻辑实施纠正，从而将LLM的创造性能力“驾驭”在可控、可预测的业务流程之内。因此，任务设计中的“强制检查点”不是对Agent能力的限制，而是使其能够在复杂现实场景中稳定、可靠工作的必要保障。

参考来源

• 一文彻底掌握 AI Agent
• 春哥的Agent通关秘籍03：格式化输出【知识篇】
• Agent 很强，但 Harness 才是那个决定成败的东西
• Prompt 编写模板：让 Agent 严格遵循 SOP 的指令设计技巧
• 现在让我们来解读协程 coroutine. co 常是一个表示:“一起“的前缀,如cooperate ，routine 有 惯例，例行程序 的意思。怎么和协程的功能作用结合起来理解呢？
• Harness Engineering是什么？为什么Harness来了，也得用混合检索？