了解智能体原理，掌握 SKILL / RULE 最佳实践

面向读者

本文适用于 AI 智能体产品、研发、实施与运维人员，也适合希望规范搭建 AI 知识库、优化模型输出质量的技术与非技术从业者。

一、底层核心：大模型的两个基础约束

1．默认不具备跨请求持久记忆

大模型通常不会自动在不同请求之间保存会话状态。
如果系统希望模型“记住”之前的内容，需要由应用侧显式提供，例如：

传入历史对话；
传入历史摘要；
传入外部记忆库中的相关信息；
从业务系统读取用户画像、任务状态或上下文数据。

因此，更准确地说，大模型并非“绝对无状态”，而是默认不自带跨请求持久记忆能力。
它在某一轮回答中能“记住”什么，取决于本轮系统实际提供了什么。

2．上下文窗口有限

大模型每次推理时可接收的信息量有限，即存在上下文长度上限。
系统在构造输入时，通常需要在以下内容之间做取舍：

系统提示词；
规则约束；
技能说明；
历史消息；
检索知识片段；
工具定义；
工具返回结果；
用户当前问题。

因此，系统不能无上限地把所有文档都塞进模型，而必须进行筛选、压缩、排序和裁剪。

智能体的核心任务之一，是在上下文、时延与成本约束下，组织最相关的信息与能力，以合适的方式提供给模型，从而提升任务完成质量。

二、模型输出受哪些因素影响

模型输出并不只由“用户输入”决定，而是由多种因素共同作用的结果。
从工程视角，可以将其拆分为两类：

1．应用侧可直接控制的因素

这类因素是系统优化的重点，包括：

系统提示词；
检索到的知识片段；
技能说明与规则约束；
工具调用结果；
解码参数，如 temperature；
安全策略与输出格式要求；
历史消息的选择与摘要方式。

2．应用侧通常难以直接控制的因素

这类因素通常难以彻底消除，只能理解和适配，包括：

模型固有参数能力；
采样随机性；
平台侧内置策略；
底层服务的隐藏实现差异。

工程实践中，重点应放在优化“可控因素”上。
只要上下文组织、规则设计、工具链和验证机制做得足够好，输出稳定性通常就能显著提升。

三、SKILL、RULE 与知识库分别是什么

在智能体系统中，SKILL、RULE 与知识库通常都属于模型参数之外的外部资源。
它们不属于模型预训练时固有掌握的内容，但可以在运行时被系统接入，从而影响模型输出。

1．SKILL：定义“会做什么、怎么做”

SKILL 更偏向能力说明与任务流程，通常用于描述：

适用场景；
执行步骤；
工具调用顺序；
输入输出要求；
回复模板；
功能边界。

它回答的是：面对某类任务，智能体应该如何处理。

2．RULE：定义“必须遵守什么、不能做什么”

RULE 更偏向约束与边界，通常用于描述：

业务红线；
安全合规要求；
禁止回答的内容；
不得泄露的信息；
输出格式约束；
风险控制规则。

它回答的是：无论执行什么任务，都必须遵守哪些要求。

3．知识库：提供“可参考的事实资料”

知识库更偏向事实信息与业务资料，通常包括：

产品资料；
FAQ；
操作手册；
政策文件；
标准说明；
领域知识。

它回答的是：模型回答时可以参考哪些事实内容。

4．三者关系

三者都可能以文本、结构化数据、工具参数、流程节点配置或外部查询结果的形式参与运行，但职责并不相同：

SKILL 偏流程与能力；
RULE 偏约束与边界；
知识库偏事实与资料。

因此，不宜将三者简单视为同一种知识，而应按用途进行分层设计与治理。

四、智能体的职责，不只是“拼接 Prompt”

“拼接 Prompt”只是智能体常见能力的一部分，而不是全部。
在实际系统中，智能体通常还承担以下职责：

意图识别；
任务分解；
工具选择与调用；
状态管理；
上下文组织；
结果校验；
风险控制；
多轮追问；
异常回退与重试。

因此，更准确的理解是：

智能体的核心，不是单纯拼接 Prompt，而是在约束条件下组织最优上下文，并对任务执行过程进行全流程管控。

五、文件是否生效，关键不在目录，而在运行链路

一个常见误解是：

“文件放进某个目录，就一定会被模型看到。”

这并不严谨。
更准确地说，某个文件是否会影响模型回答，通常取决于以下机制：

是否被系统纳入配置范围；
是否被绑定到某个智能体、技能或工作流；
是否被建立索引；
是否被作为系统提示词常驻；
是否能被本轮检索、匹配或调用到；
是否在本轮请求中被实际注入上下文；
是否被权限或长度裁剪机制过滤。

一个典型的生效链路

文件存储
→ 系统配置（绑定智能体 / 技能 / 工作流）
→ 建立索引 / 常驻提示词 / 注册工具
→ 本轮请求检索 / 调用 / 读取
→ 注入模型上下文
→ 影响模型输出

在常见架构下，若关键链路未生效，例如：

未绑定；
未建立索引；
检索未命中；
本轮未注入；
注入后被裁剪掉；

那么该文件通常不会影响本轮回答。

因此，目录位置通常只是管理手段，不是最终决定文件是否生效的根本因素。

六、智能体如何让模型“知道该说什么”

智能体并不是把所有文档原样发给模型，而是根据当前问题动态构造“本轮最有用的运行时上下文”。

一个典型流程通常包括：

1．资源准备

系统预先组织规则、技能文档和知识资料。
常见方式包括：

文档切块；
向量索引；
关键词索引；
标签分类；
结构化字段建模；
工作流配置；
工具定义注册。

2．用户发起问题

用户提交当前任务请求。

3．系统识别意图并选择资源

系统结合当前问题、历史上下文和业务策略，决定是否需要：

检索知识；
调用工具；
启用某个技能；
加载某项规则；
先向用户补充追问。

4．召回、筛选与重排

系统从候选资源中挑选最相关内容，并进行：

相关性排序；
去重；
冲突消解；
摘要压缩；
优先级安排；
长度裁剪。

5．组装运行时上下文

本轮送入模型的内容，可能包括：

系统指令；
规则约束；
技能说明；
知识片段；
历史消息；
工具定义；
工具执行结果；
用户当前问题。

6．模型生成回答或发起下一步动作

模型基于本轮可见信息生成回复，或者：

请求缺失参数；
调用函数；
输出结构化结果；
进入下一轮决策。

从模型视角看，它只能访问本轮实际传入的内容。
未被传入的文档、规则或数据，对模型而言就是不可见的。

七、为什么说“最终都要转化为模型可消费的信息”

无论是 SKILL、RULE 还是知识库，想影响模型行为，都必须转化为某种运行时可用形式，例如：

系统提示词中的约束；
检索命中的知识片段；
工具参数说明；
结构化字段；
工作流节点输出；
代码执行结果；
外部系统返回的数据。

因此，外部知识不是“存进去就自然有效”，而是必须被系统以可执行、可消费、可引用的方式接入后，才真正参与推理。

八、SKILL 的推荐写法与反例

正面示例

# 技能：订单查询

## 适用场景
当用户询问订单状态、订单金额、创建时间等订单基础信息时使用本技能。

## 执行步骤
1. 优先询问用户订单号。
2. 若用户无法提供订单号，可询问其绑定手机号作为辅助查询条件。
3. 调用 tool_order_query 工具获取订单详情。
4. 仅返回订单状态、创建时间、支付金额三个字段。
5. 不返回手机号、地址、身份证号等隐私信息。

## 回复格式
订单号：{order_no}
状态：{status}
创建时间：{create_time}
支付金额：{amount} 元

反面示例

订单查询的话就是先要信息，然后去查一下，然后告诉用户，有时候要订单号有时候要手机号看情况，查完就把结果返回，注意不要说太多，大概说一下就行，另外金额也要说一下。

常见问题

表述模糊；
条件不明确；
步骤不稳定；
输出边界不清晰；
不利于检索、复用和维护。

九、RULE 的推荐写法与反例

正面示例

# 全局规则

## 禁止行为
1. 不得回答政治、色情、暴力等敏感内容。
2. 严禁泄露用户手机号、地址、身份证号等隐私信息。
3. 不得承诺无法确认或无法保证的服务结果。

## 格式约束
1. 统一使用中文全角标点符号。
2. 所有金额数值保留 2 位小数。
3. 输出应简洁清晰，不使用复杂 Markdown 排版。

反面示例

回答要注意分寸，不该说的别乱说，隐私要保护好，有时候不能乱承诺，格式也要正常点，别乱七八糟的，价格要对。

常见问题

判定标准不明确；
主观描述过多；
难以形成稳定执行约束。

十、SKILL 与 RULE 是否必须拆分

从工程实践看，建议按职责分层管理，但不必绝对化理解为“必须拆成两个文件”。

1．小型智能体 / 单一场景

可合并在同一文件中，但应分层书写。

适用原因：

配置简单；
场景单一；
避免过度设计。

2．中大型智能体 / 多场景系统

建议物理拆分，并统一治理。

适用原因：

便于权限控制；
便于版本迭代；
便于冲突排查；
规则变更与流程调整可解耦。

3．高合规要求场景

建议 RULE 独立存储，并叠加代码级强约束。

适用原因：

规则需单独审计；
生效链路需可追溯；
不能把核心合规能力完全寄托于文本注入；
避免规则因上下文裁剪而失效。

因此，真正关键的不是“是否拆成两个文件”，而是职责边界是否清楚、优先级是否明确、治理链路是否可靠。

十一、文档编写的实践原则

1．使用可执行表述，避免模糊语句

优先使用：

“必须”
“仅允许”
“禁止”
“保留 2 位小数”
“仅返回以下字段”

尽量少用：

“看情况”
“大概”
“尽量”
“注意一点”
“不要太多”

2．采用稳定结构

推荐模板如下：

# 【类型】XXX
## 适用场景
明确触发条件

## 核心内容
- SKILL：执行步骤 + 工具调用 + 输出模板
- RULE：禁止行为 + 格式约束 + 合规要求
- 知识库：事实描述 + 数据来源 + 更新时间

## 例外条件
特殊场景处理方式

## 生效范围
绑定的智能体 / 技能 / 用户范围

3．减少冗余与重复

同一规则不宜在多个位置反复维护，否则容易产生版本冲突。

4．为“检索与治理”而写

文档不仅是给人看的，也是在为系统后续的切块、检索、排序、引用、回归测试和版本治理服务。

十二、效果验证建议

规范写完后，必须验证。至少建议做以下三类测试：

1．验证“文件是否生效”

构造测试问题，对比：

注入该文件时的输出；
不注入该文件时的输出。

观察差异，确认该文件是否真实影响模型行为。

2．验证“规则是否落地”

故意触发限制场景，例如：

询问隐私信息；
请求违规承诺；
要求输出敏感内容。

检查模型是否正确执行：

拒绝；
脱敏；
风险提示；
转人工。

3．验证“结构是否有效”

尝试调整文档结构，例如：

合并段落；
拆分章节；
修改标题；
调整切块边界。

观察检索命中率、回答一致性与稳定性变化。

好文档不是“写完就结束”，而是要经过测试、回归和迭代验证。

十三、常见避坑点

1．不要把所有规则都写成文本提示词

核心合规要求，如隐私脱敏、权限校验、关键字段过滤，应尽量配合代码或流程强约束。

2．不要依赖单一检索方式解决所有问题

知识类内容适合检索召回；
规则类内容通常更适合作为常驻约束或高优先级匹配资源；
工具调用类内容则更适合流程控制与程序约束。

3．不要认为文档写好就一劳永逸

文档更新后，通常还需要：

重新索引；
回归测试；
验证命中情况；
检查旧规则是否冲突；
评估上下文成本变化。

十四、关键结论总结

大模型默认不自带跨请求持久记忆，也不天然掌握你的私有业务知识。
若希望其“记住”或“知道”，需要由系统在运行时提供相关上下文或外部能力。
模型输出由多因素共同决定。
工程上应重点优化应用侧可控因素，如系统提示词、规则设计、检索内容、工具结果和解码参数。
SKILL、RULE、知识库应按职责分层管理。
SKILL 偏流程与能力，RULE 偏约束与边界，知识库偏事实与资料；是否物理拆分取决于复杂度和治理要求。
文件是否影响模型输出，关键在运行链路是否生效。
是否被加载、绑定、索引、命中并注入本轮上下文，才是真正决定因素，目录位置通常只是辅助管理方式。
智能体的核心是“组织最优上下文 + 全流程管控”。
它不仅负责信息注入，还承担意图识别、工具调用、状态管理、安全控制和结果校验等职责。
清晰结构是基础，但不是全部。
文档质量需要与检索策略、提示词设计、工具链、代码约束和评测机制协同，才能形成稳定效果。

posted on 2026-03-28 08:18 岚天逸见阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

岚天逸见