新一代提示词工程 · 知识全景图面向有工程基础、提示词工程尚未系统化的工程师
显示设置

我的 agent 的提示词面

My Agent's Prompt Surface

PE-P-01内容已写满G09落地实践第 16 层

落地实践提示词面盘点

一句话结论

提示词面要按常驻、按需、传递、判据四层盘点,每个部件都标出注入条件与验证方式。

本页结构(可跳转)

S 提示词面:一个 agent 的行为不只由系统提示决定 L1 常驻层 系统提示 · 工具定义 安全规则 S->L1 L2 按需层 技能文件 · 检索资料 外部文档 S->L2 L3 传递层 子 Agent 任务描述 与返回契约 S->L3 L4 判据层 门控脚本 · 校验器 评测集判据 S->L4 N 四层的更新节奏与验证方式不同 常驻层改动影响面最大 ⇒ 必须跑全量回归 按需层用渐进式披露控制占用 传递层需要契约稳定 判据层自身也需要负向自检 R 盘点的产出是一张清单 标注每部分的常驻策略 · 更新频率 · 验证方式 这张清单本身就是后续优化的依据
结构图:提示词面的四层构成(常驻 / 按需 / 传递 / 判据)、各自的验证方式,以及盘点产出的清单形态。 (本站自制)

01为什么需要它

一个 agent 的行为不只由系统提示决定:工具定义、技能的触发描述、子 Agent 的委派模板、记忆与检索注入、门控判据都在同一时刻影响它。

适用边界

提示词面的构成随运行时不同而不同,本节点的四层划分与清单来自使用者自己的 agent 运行环境,换一个运行时需要重新盘点,不能直接照搬。

02机制说明

盘点提示词面按四层进行。

03何时该用 / 何时不该用

按场景对照:先看条件,再看该怎么做。
类别场景 / 条件(总结)具体做法(细节)
该用优化 agent 行为前先盘点提示词面,确认问题出在常驻层、按需层、传递层还是判据层。
该用上下文占用过高时检查技能正文与检索资料是否被误设为常驻,改用短触发描述加按需展开。
不该用把系统提示当成唯一的优化对象工具描述、委派模板与记忆注入同样决定行为。
不该用照搬本清单到其他运行时提示词面的构成随运行时而异,换环境须重新盘点。

04实验台

  1. filemarkdown

    查看代码
    # 提示词面盘点清单(逐部件一行,填完即可看出这面有多大)
    
    | 部件 | 所在位置 | 注入条件 | 更新频率 | 验证方式 |
    |---|---|---|---|---|
    | 系统提示 | <路径> | 常驻 | 低 | 全量回归 |
    | 工具描述 | <路径> | 常驻 | 中 | 工具选择评测 |
    | 技能触发描述 | <路径> | 常驻 | 中 | 触发命中率 |
    | 技能正文 | <路径> | 按需(被选中后展开) | 高 | 单技能评测 |
    | 检索资料 | <路径> | 按需注入 | 高 | 引用正确性抽查 |
    | 委派模板 | <路径> | 委派时 | 中 | 返回契约校验 |
    | 记忆条目 | <路径> | 按需注入 | 高 | 过期复核 |
    | 门控判据 | <路径> | 不注入模型 | 中 | 负向自检 |
    
    ## 填完要回答的三个问题
    1. 常驻部件的合计占用是多少?
    2. 哪些部件本该按需却被设成了常驻?
    3. 每个部件改动之后,用哪一条判据证明它变好了?

    预期观察:读者得到一张覆盖常驻、按需、传递、判据四层的清单,每个部件都写明了注入条件与验证方式;清单里标记为常驻却更新频繁的部件,就是下一步该改成按需加载的对象。

  2. shellbash

    查看代码
    # 量一遍常驻占用:逐个列出常驻层部件,看谁最贵
    for f in prompt/system.md prompt/tools/*.json prompt/skills/*/SKILL.md; do
      [ -f "$f" ] || continue
      wc -m "$f"
    done
    
    # 按需层只应在被选中后展开:技能正文与引用文件不应出现在常驻清单里
    for f in prompt/skills/*/references/*.md; do
      [ -f "$f" ] || continue
      echo "按需:$f"
      wc -m "$f"
    done

    预期观察:输出是一张常驻占用清单:系统提示、工具描述与技能触发描述各占多少字一目了然;若某个技能的正文出现在常驻清单里,就说明它没有被拆成短触发描述加按需引用文件。

05证据

主张官方把上下文工程定义为推理时点对全部进入上下文窗口的 token 的管理,并明确包含落在提示词之外的信息,因此提示词面不能等同于提示词文本本身。

分级official

来源S-0004 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

原文

展开原文关键句 原文截断
the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference ... including all the other information that may land there outside of the prompts.

主张工具描述被官方明确列为可精简对象,且精简后任务表现与 token 效率同时改善,说明工具描述属于提示词面且值得单独审计。

分级official

来源S-0012 https://developers.openai.com/api/docs/guides/latest-model

原文

展开原文关键句 原文截断
Removing repeated instructions and examples and simplifying tool descriptions can improve task performance and token efficiency.

主张官方把注入的入口列为直接输入、检索内容、工具输出、中间推理与持久记忆,这些正是提示词面里会被写入的部件,因此记忆与上下文注入必须按不可信内容对待。

分级official

来源S-0032 https://raw.githubusercontent.com/GenAI-Security-Project/GenAI-LLM-Top10/main/2026/final/LLM01_PromptInjection.md

原文

展开原文关键句 原文截断
whether direct user input, retrieved content, tool output ... persistent memory, alters the model's behavior in ways the application developer did not intend.

主张官方现行立场:技能曾被写成详尽行程单与配方,而过度具体的指导如今反而可能损害结果,因此技能描述应尽可能短。

分级official

来源S-0013 https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra

原文

展开原文关键句 原文截断
many skills were written as elaborate itineraries or recipes. ... overly specific guidance can now hinder results where it previously helped. ... skill descriptions should be as short as possible

06术语

术语渐进式披露 Progressive Disclosure

界定提示资产只在前端暴露最短的触发描述与索引,把细节留到确实需要时再加载,以压低常驻上下文占用。

相关节点—

术语工具定义与滥用治理 Tool Definition and Abuse Governance

界定工具的名称、描述与参数模式构成提示词面的一部分;描述含糊会诱发误用,工具过多会诱发滥用与误选。

相关节点—

术语子 Agent 委派与返回契约 Sub-agent Delegation and Return Contract

界定主 Agent 向子 Agent 交付的自包含任务描述与其必须回传的结构化结果约定,二者共同决定委派是否可被验证。

相关节点—

07失效模式

08在本站知识结构中的位置

所属分组
G09落地实践
依赖深度
第 16 层(同层节点彼此无先后约束)
前置PE-O-08 架构在册→PE-P-01 本节点→后继PE-P-02

在 交互全景图 中定位本节点。