复杂提示工程到可维护提示：分层 Prompt 与模板化

许多团队在用 n8n 搭建 AI Agent 流程时，会遭遇几个共性难题：指令散落各处、版本不可追、上下文容易漂移、结果难以复测与回归。工程上更稳妥的做法，是把与模型交互的「指令」与「模板」当成可维护的构件，像服务配置一样纳入治理与测试体系。

是什么

从工程视角看，指令并非一次性的文案，而是可复用的结构化资产。它通常由以下部分组成：

• 平台级原则：贯穿所有任务的通用规范（安全、合规、风格、输出格式）。
• 领域策略：和业务相关的知识与术语（如客服、法务、医药等的专属约束）。
• 技能模块：可组合的能力说明（摘要、分类、抽取、工具使用等）。
• 任务实例：目标、输入、约束、验收条件等具体化指令。
• 记忆与上下文：短期会话缓冲与长期知识库（如 local_content、CRM、向量库）。
• 工具接口：外部调用的契约（搜索、数据库、HTTP API），以及输出的结构化要求。

将以上要素做成可组装、可测试、可版本化的模板与配置，才能在 n8n 等自动化平台中长期稳定地驱动 Agent。

为什么

把指令工程化的价值体现在以下方面：

• 可维护：不同流程共享同一策略与模板，集中升级，减少重复修改。
• 可治理：版本、审批、审计清晰，方便合规与风险控制。
• 可测试：A/B 与回归测试标准化，故障定位更快。
• 可扩展：新增技能或工具时，只需增量拼装而非重写整段指令。
• 可迁移：跨模型与框架迁移更容易（如从闭源到开源模型）。

怎么做

下面以 n8n 为主线给出落地路径与一个可运行的最小实例。

1. 建立多级结构
   • 把平台级原则、领域策略、技能模块、任务实例拆分为独立文件或节点变量。
   • 在 n8n 使用「Set」「Function」「Merge」等节点，动态组合当次任务的指令包。
2. 模板与插槽
   • 在「Set」或「Function」节点维护模板文本，使用插槽变量（如 {{task_goal}}、{{constraints}}）。
   • 输入通过前置节点（Webhook/Trigger/Database）填充，避免把具体数据硬编码进模板。
3. 结构化输出契约
   • 为模型输出定义 JSON Schema 或表格规约，并在后置节点做校验与纠错。
   • 不依赖模型自由发挥，明确键名、类型、枚举与必填项。
4. 版本与发布
   • 把模板与策略文件放入 Git；n8n 中使用环境变量区分 dev/stage/prod。
   • 发布前在「Test」工作流中跑基准数据集（golden set）进行回归。
5. 评测与防漂移
   • 为关键任务设定断言（IF/Switch 节点）与评分脚本，出现异常自动回退或降级处置。
   • 记录每次调用的输入、指令包、输出与评分，便于溯源与调参。

一个示例「Function」节点代码（在 n8n 中组装上下文与模板）：

// n8n Function Node
// 输入：来自上游节点的 policy、domain、skill、task、constraints、memory 等
// 输出：messages（供下游 LLM/HTTP Request 节点使用），以及预期的 JSON Schema 提示

const policy = items[0].json.policy || [
  "遵守公司安全与合规要求",
  "默认用简体中文回答",
  "优先输出结构化结果"
];

const domain = items[0].json.domain || [
  "领域：SaaS 销售线索",
  "术语：ICP、MQL、SQL"
];

const skill = items[0].json.skill || [
  "能力：分类与关键信息抽取",
  "可以调用外部工具：公司域名查询、邮箱验证"
];

const task = items[0].json.task || {
  goal: "判断来信是否为有效销售线索并抽取关键字段",
  inputs: {
    emailSubject: $json.emailSubject,
    emailBody: $json.emailBody
  },
  constraints: [
    "必须给出置信度 0~1",
    "若信息缺失，标记 missing_fields"
  ],
  accept: [
    "输出 JSON，包含 is_lead, confidence, company, contact, missing_fields"
  ]
};

const systemText = [
  ...policy,
  ...domain,
  ...skill,
  "输出必须为 JSON，不要附加解释"
].join("n");

const userText = [
  `目标：${task.goal}`,
  `输入：主题=${task.inputs.emailSubject}`,
  `输入：正文=${task.inputs.emailBody}`,
  `约束：${task.constraints.join("；")}`,
  `验收：${task.accept.join("；")}`
].join("n");

const messages = [
  { role: "system", content: systemText },
  { role: "user", content: userText }
];

return [{ json: { messages } }];

在下游使用「HTTP Request」或专属 LLM 节点发送 messages，并要求返回严格 JSON；随后通过「IF」「Function」校验键名与类型。

一个贴近业务的案例：销售线索资格判定 Agent。

• 入口：收件箱 Webhook 抓取新邮件。
• 预处理：解析主题/正文，调用域名信息查询工具补充公司信息。
• 组装指令：合并平台级原则、领域策略与技能模块，实例化当次任务。
• 模型调用：返回严格 JSON（is_lead、confidence、company、contact、missing_fields）。
• 校验与纠错：IF 节点断言键存在与类型正确，不符则二次修正或人工审查。
• 落库与通知：写入 CRM/Postgres，并在 Slack/邮件告知结果与评分。

在这一流程中，local_content 可作为本地知识库（如历史客户画像、ICP 定义）参与检索增强；通过向量库检索将相关片段拼入指令包，提高判断准确度与一致性。

扩展思考

当流程被工程化后，可以继续向下打磨：

• 守护与合规：为高风险任务加「审批节点」与「红线词表」，输出不合规自动阻断。
• 结构化交互：尽可能使用模式化输出与函数调用，减少自由文本的歧义。
• 多代理协作：将复杂流程拆成多个角色协作，通过消息路由与共享记忆保持一致性。
• 成本与性能：引入缓存与蒸馏模型做前置筛选，把大模型用在关键路径。
• 可观测性：把「指令包」「输入」「输出」「评分」落到日志与时序库，便于趋势分析与异常告警。

治理的核心不是堆砌技巧，而是让人与模型的对话成为可测试、可追踪、可复用的系统。

结语

总结：将与模型交互的指令做成结构化资产，拆分为多级构件，并在 n8n 中以模板、变量、契约、版本、评测的方式治理，能显著提升 AI Agent 的稳健性与可维护性。

思考：你的团队目前哪一类任务最需要结构化治理？不妨从一个最小场景（如邮件分类与抽取）开始建立基准与模板，逐步扩展到更复杂的流程。

如果你希望获得更多自动化与 Agent 落地方案，欢迎关注 Dr.n8n（drn8n.com）与相关生态的持续实践与工具集。