尧图网站建设 
Parlant 词表Glossary实战为 LLM Agent 构建领域专属词汇表【免费下载链接】parlantBuild reliable customer-facing AI agents with Parlant: an interaction control harness optimized for controlled, consistent, and predictable LLM interactions.项目地址: https://gitcode.com/GitHub_Trending/pa/parlant词表Glossary是 Parlant 塑造 Agent 领域理解的基础机制它相当于 Agent 的专业词典由一组特定于你的业务或服务场景的术语组成。本文基于 glossary.md 展开讲解词表术语的创建、结构、Agent 对词表的使用方式以及词表与 Guideline行为准则、Agent Description、Tool 的边界划分并结合 src/parlant/core/glossary.py 与 src/parlant/core/engines/alpha/engine.py 的源码实现剖析术语从创建、向量存储到提示词注入的完整链路。读完本文你将掌握如何用agent.create_term()创建术语name / description / synonyms 三要素Agent 如何借助词表正确理解客户措辞、并正确匹配依赖这些术语的 Guideline词表在源码层的存储结构向量库 文档库、语义检索逻辑与提示词注入机制何时该用词表、何时该用 Guideline 或 Tool避免三者混用。一、何时需要词表当你创建一个 Agent 来处理特定任务时它往往需要理解你领域的独特词汇。Parlant 官方文档给出的经典例子是如果你的 Agent 负责为 Boogie Nights 酒店的客人订房它必须知道 Boogie Nights 在你的语境下不是那部电影的片名而是酒店的名字。这类同名歧义在真实业务中非常普遍token可以是代币、认证令牌或聊天 tokenwallet可以是钱包应用或加密钱包。如果不在词表中明确定义LLM 会依据其通用语料库的常识去理解导致答非所问。二、术语的结构与创建2.1 术语三要素每个词表条目由三个部分组成Term术语被定义的单词或短语Description描述该术语在你的特定语境下的含义Synonyms同义词用户可能用来指代该术语的其他说法。2.2 通过 SDK 创建术语Parlant SDK 中术语通过 Agent 对象的create_term()方法创建await agent.create_term( nameTERM, descriptionDESCRIPTION, synonyms[SYNONYM_1, SYNONYM_2, ...], )一个完整示例酒店场景await agent.create_term( nameBoogie Nights, descriptionOur luxury beachfront hotel located in Miami, synonyms[BN Hotel, The Boogie, Boogie Hotel], )从源码看SDK 的create_term()完整签名为见 sdk.py#L3629async def create_term( self, name: str, description: str, id: Optional[TermId] None, synonyms: Sequence[str] [], ) - Term: ...即除了三个核心要素外还可以传入可选的自定义idTermId类型来指定术语 ID——这在需要幂等创建或跨系统对齐 ID 时很有用tests/sdk/test_glossary.py 中的Test_that_a_glossary_term_can_be_created_with_custom_id用例即验证了该能力。还有一个文档未提及但源码中明确的行为SDK 会自动为每个术语打上当前 Agent 的标签。在create_term()内部术语最终是以tags[_Tag.for_agent_id(self.id).id]写入GlossaryStore的。这意味着通过某个 Agent 创建的术语默认归属于该 Agent而在引擎层检索时系统会同时合并Agent 专属术语 通过 Agent 标签关联的术语 全局术语未打标签三类来源见 entity_cq.py#L286-L302 的find_glossary_terms_for_context为术语的作用域管理留出了余地。2.3 底层数据模型术语在核心层由不可变数据类Term表达见 glossary.py#L49-L56dataclass(frozenTrue) class Term: id: TermId creation_utc: datetime name: str description: str synonyms: list[str] tags: list[TagId]Term的__repr__会把术语格式化为Name: xxx, Description: xxx, Synonyms: a, b的字符串——这个格式后续会直接进入 LLM 提示词见第四节。三、词表在源码层的存储与检索机制3.1 双库存储向量库 文档库术语的持久化由GlossaryVectorStore实现glossary.py#L166它在初始化时同时创建两个集合向量集合glossaryVectorDatabase 上存放术语文档及其语义向量用于相似度检索文档集合glossary_tagsDocumentDatabase 上存放术语与标签TermTagAssociationDocument的关联记录。写入术语时系统先调用_assemble_term_content()把三要素拼成一段可被嵌入的文本再计算xxh3校验和写入glossary.py#L484-L497def _assemble_term_content(self, name, description, synonyms) - str: content f{name} if synonyms: content f, {, .join(synonyms)} content f: {description} return content也就是说向量检索的输入文本形如Boogie Nights, BN Hotel, The Boogie, Boogie Hotel: Our luxury beachfront hotel located in Miami。同义词会参与向量化这正是用户说 The Boogie 也能命中 Boogie Nights的底层原因。术语 ID 默认由xxh3_checksum(f{name}{description}{synonyms})派生因此相同内容的术语 ID 是确定性的除非显式传入自定义id。3.2 语义检索find_relevant_termsGlossaryStore.find_relevant_terms(query, available_terms, max_terms20)是词表检索的核心抽象glossary.py#L111-L117。其实现要点若候选术语数量不超过max_terms直接全部返回跳过向量检索否则用query_chunks()将查询切块对每个块执行find_similar_documents(..., kmax_terms)带hints{tag: glossary_terms}提示合并去重后按向量距离distance升序排序取前max_terms个返回。默认上限为 20 个术语。当词表规模不大时全部术语都会进入上下文规模更大时只有与当前对话最相关的术语会被选中注入提示词。四、Agent 如何使用词表两个用途 源码链路官方文档指出词表在 Agent 交互中承担两个关键用途理解客户当客人说 Id like to stay at The Boogie 时Agent 知道这指的是你的酒店正确解释 Guideline当 Guideline 的 condition/action 引用了领域术语时Agent 需要靠词表理解其含义。4.1 词表驱动 Guideline 匹配的典型配置文档中的完整示例await agent.create_guideline( conditionthe user asks about Ocean View rooms, actionexplain the Sunrise Package benefits, ) await agent.create_term( nameOcean View, descriptionOur premium rooms on floors 15-20 facing the Atlantic, synonyms[seaside rooms, beach view], ) await agent.create_term( nameSunrise Package, descriptionComplimentary breakfast and early check-in for Ocean View bookings, synonyms[morning special, sunrise special], )在此配置下condition 与 action 都依赖 Agent 理解这些术语。当客户说Customer:I heard you have some rooms with a view to the Atlantic. What are those?客户既没提 Ocean View 也没提 beach view只说了 a view to the Atlantic。但基于词表中Ocean View的定义facing the AtlanticAgent 可以判定 conditionthe user asks about Ocean View rooms已满足进而执行 actionexplain the Sunrise Package benefits。4.2 源码链路从消息到提示词上述靠定义而非字面量匹配术语的能力在引擎中由一条清晰的调用链支撑第一步构建检索查询。每轮处理时引擎调用_load_glossary_terms(context)engine.py#L1864把当前上下文拼成一个语义查询上下文变量context variablesJSON 化当前交互事件客户消息等已加载 Guideline 的条件/动作文本When {condition}, then {action}已产生的工具事件数据tool events。然后交给find_glossary_terms_for_context()做向量检索。注意 Guideline 文本本身也参与查询——这正是Agent 根据 Guideline 内容反向召回相关术语的实现即使客户还没提到某术语只要 Guideline 引用了它对应术语也可能被召回进上下文。第二步多次刷新防止术语漏配。引擎不仅在首轮加载词表还会在 Guideline 匹配后和工具调用返回后各刷新一次engine.py#L646-L648、engine.py#L699-L701# Matched guidelines may use glossary terms, so we need to ground our # prompt with any glossary terms the guidelines may reference. context.state.glossary_terms.update(await self._load_glossary_terms(context))# Tool calls may have returned with data that uses glossary terms, # so we need to ground our prompt with any glossary terms the tools may reference. context.state.glossary_terms.update(await self._load_glossary_terms(context))这对应文档中静态知识 动态数据的衔接工具返回的数据里若包含领域术语也会被二次召回并注入后续提示词。第三步注入提示词。召回的术语最终通过PromptBuilder.add_glossary()写入系统提示词的 GLOSSARY 段prompt_builder.py#L403-L425模板原文如下The following is a glossary of the business. Understanding these terms, as they apply to the business, is critical for your task. When encountering any of these terms, prioritize the interpretation provided here over any definitions you may already know. Please be tolerant of possible typos by the user with regards to these terms, and let the user know if/when you assume they meant a term by their typo: ### {terms_string} ###这段模板透露了两个值得注意的工程设计定义优先级明确指示 LLM 对术语优先采用此处给出的解释覆盖你已知的任何定义——这是压制 LLM 通用常识、实现领域语义接管的关键指令容错与透明要求 LLM 对用户可能的拼写错误保持宽容并在做出我理解你指的是 X的假设时主动告知用户。同时生成秘密性规则要求 Agent 不得向客户暴露glossary、guidelines 等内部机制的存在见 canned_response_generator.py#L1448glossary.feature 中就有专门场景验证这一点Scenario: The agent explains term without exposing the glossary itself Given the term token defined as a digital token And a customer message, what is a token? When processing is triggered Then a single message event is emitted And the message contains an explanation about what a token is, without mentioning that it appears in a glossary五、测试证据词表能力的可验证行为BDD 场景文件 系统性地验证了文档所述的两类用途值得作为回归基线阅读歧义术语解释客户理解分别定义了token数字代币、wallet数字钱包、mining加密货币挖矿、private key、gas以太坊费用等极易歧义的词验证客户直接询问时 Agent 按词表定义回答Guideline 按术语名/定义触发Guideline 解释Scenario: The agent follows a guideline that mentions a term by name Given the term walnut defined as the name of an altcoin And a guideline to say Keep your private key secure when the customer asks how to protect their walnuts And a customer message, How do you keep walnuts secure? ... Scenario: The agent follows a guideline that refers to a terms definition Given the term walnut defined as the name of an altcoin And a guideline to say Keep your private key secure when the customer asks how to protect their financial assets And a customer message, How do I protect my walnuts? ...前一个场景中 Guideline 直接引用术语名 walnut后一个场景中 Guideline 引用的是术语的定义financial assets ↔ altcoin两个场景都应命中——这正是词表定义级匹配能力的双向验证从 Guideline / Tool 内容召回术语场景 The agent responds with a term retrieved from guideline content 中故意放入 50 个干扰术语验证引擎能基于 Guideline 文本召回正确的 leafwalnut 币的加密钱包工具场景则验证从 tool 返回内容中召回术语。SDK 层的持久化正确性含自定义 ID则由 tests/sdk/test_glossary.py 覆盖。六、词表 vs Guideline vs Agent Description文档明确三者的分工这是设计 Agent 时最容易混淆的地方Glossary 教 Agent事物是什么。例如A Club Member is a guest who has stayed with us more than 5 times. 术语数量不设限Guidelines 教 Agent在情境中如何行动。例如When speaking with Club Members, acknowledge their loyalty status. 数量同样不设限Agent Description 提供整体语境与个性。例如You are a helpful hotel booking assistant for Boogie Nights. 它是静态且有限的。可以这样理解词表构建 Agent 的词汇量Guidelines 塑造其行为Agent Description 设定其整体语境、角色、个性与语气。把定义写进 Description 会挤占有限的静态空间且无法参与语义检索把行为写进词表则会失去 Guideline 的条件-动作执行机制。七、词表 vs 工具静态知识与动态数据的分界词表术语和工具都能帮助 Agent 理解你的领域但目的根本不同词表提供静态知识工具提供动态数据访问。以酒店预订为例词表术语字段值TermClub MemberDescriptionA guest who has stayed with us more than 5 timesSynonymsloyal guest, regular guest对应工具check_member_status(user_id) # Returns current stay count and benefits词表术语提供Club Member 是什么的一致定义而工具能查询某个具体用户在你数据库中的实际状态。同理词表术语字段值TermOcean View RoomDescriptionPremium rooms on floors 15-20 facing the AtlanticSynonymsseaside room, beach view对应工具check_room_availability(room_type, dates) # Returns current availability and rates词表帮助 Agent 理解 Ocean View Room 是什么工具则提供具体房型实时的可用性与时价。这种静态知识词表与动态数据访问工具的分离能构建出清晰、可维护的 Agent 实现通用问询由词表兜底理解数据驱动的具体交互交给工具。从源码视角看两者在引擎中是互补而非竞争关系——工具事件数据会反过来参与词表检索查询第四节的第二步形成工具返回值里的术语 → 词表解释 → 提示词的闭环。八、实践建议小结为每个高歧义业务实体建术语酒店名、房型、套餐名、会员等级等且尽量多给同义词同义词参与向量化直接提升召回率Guideline 引用术语时用定义 术语名双通道表述如 BDD 测试所示词表同时支持按名称和按定义触发 Guideline条件文本写得越贴近客户实际措辞匹配越稳控制术语规模以适配 20 个的默认召回上限find_relevant_terms默认max_terms20术语总量过多时只有语义最相关的会进入提示词与核心业务无关的长尾术语可考虑按 Agent 标签拆分作用域定义与行为、实时数据各归其位定义进词表情境行为进 Guideline实时查询进工具三者不互相替代。【免费下载链接】parlantBuild reliable customer-facing AI agents with Parlant: an interaction control harness optimized for controlled, consistent, and predictable LLM interactions.项目地址: https://gitcode.com/GitHub_Trending/pa/parlant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Parlant 词表（Glossary）实战：为 LLM Agent 构建领域专属词汇表
Parlant 词表Glossary实战为 LLM Agent 构建领域专属词汇表【免费下载链接】parlantBuild reliable customer-facing AI agents with Parlant: an interaction control harness optimized for controlled, consistent, and predictable LLM interactions.项目地址: https://gitcode.com/GitHub_Trending/pa/parlant词表Glossary是 Parlant 塑造 Agent 领域理解的基础机制它相当于 Agent 的专业词典由一组特定于你的业务或服务场景的术语组成。本文基于 glossary.md 展开讲解词表术语的创建、结构、Agent 对词表的使用方式以及词表与 Guideline行为准则、Agent Description、Tool 的边界划分并结合 src/parlant/core/glossary.py 与 src/parlant/core/engines/alpha/engine.py 的源码实现剖析术语从创建、向量存储到提示词注入的完整链路。读完本文你将掌握如何用agent.create_term()创建术语name / description / synonyms 三要素Agent 如何借助词表正确理解客户措辞、并正确匹配依赖这些术语的 Guideline词表在源码层的存储结构向量库 文档库、语义检索逻辑与提示词注入机制何时该用词表、何时该用 Guideline 或 Tool避免三者混用。一、何时需要词表当你创建一个 Agent 来处理特定任务时它往往需要理解你领域的独特词汇。Parlant 官方文档给出的经典例子是如果你的 Agent 负责为 Boogie Nights 酒店的客人订房它必须知道 Boogie Nights 在你的语境下不是那部电影的片名而是酒店的名字。这类同名歧义在真实业务中非常普遍token可以是代币、认证令牌或聊天 tokenwallet可以是钱包应用或加密钱包。如果不在词表中明确定义LLM 会依据其通用语料库的常识去理解导致答非所问。二、术语的结构与创建2.1 术语三要素每个词表条目由三个部分组成Term术语被定义的单词或短语Description描述该术语在你的特定语境下的含义Synonyms同义词用户可能用来指代该术语的其他说法。2.2 通过 SDK 创建术语Parlant SDK 中术语通过 Agent 对象的create_term()方法创建await agent.create_term( nameTERM, descriptionDESCRIPTION, synonyms[SYNONYM_1, SYNONYM_2, ...], )一个完整示例酒店场景await agent.create_term( nameBoogie Nights, descriptionOur luxury beachfront hotel located in Miami, synonyms[BN Hotel, The Boogie, Boogie Hotel], )从源码看SDK 的create_term()完整签名为见 sdk.py#L3629async def create_term( self, name: str, description: str, id: Optional[TermId] None, synonyms: Sequence[str] [], ) - Term: ...即除了三个核心要素外还可以传入可选的自定义idTermId类型来指定术语 ID——这在需要幂等创建或跨系统对齐 ID 时很有用tests/sdk/test_glossary.py 中的Test_that_a_glossary_term_can_be_created_with_custom_id用例即验证了该能力。还有一个文档未提及但源码中明确的行为SDK 会自动为每个术语打上当前 Agent 的标签。在create_term()内部术语最终是以tags[_Tag.for_agent_id(self.id).id]写入GlossaryStore的。这意味着通过某个 Agent 创建的术语默认归属于该 Agent而在引擎层检索时系统会同时合并Agent 专属术语 通过 Agent 标签关联的术语 全局术语未打标签三类来源见 entity_cq.py#L286-L302 的find_glossary_terms_for_context为术语的作用域管理留出了余地。2.3 底层数据模型术语在核心层由不可变数据类Term表达见 glossary.py#L49-L56dataclass(frozenTrue) class Term: id: TermId creation_utc: datetime name: str description: str synonyms: list[str] tags: list[TagId]Term的__repr__会把术语格式化为Name: xxx, Description: xxx, Synonyms: a, b的字符串——这个格式后续会直接进入 LLM 提示词见第四节。三、词表在源码层的存储与检索机制3.1 双库存储向量库 文档库术语的持久化由GlossaryVectorStore实现glossary.py#L166它在初始化时同时创建两个集合向量集合glossaryVectorDatabase 上存放术语文档及其语义向量用于相似度检索文档集合glossary_tagsDocumentDatabase 上存放术语与标签TermTagAssociationDocument的关联记录。写入术语时系统先调用_assemble_term_content()把三要素拼成一段可被嵌入的文本再计算xxh3校验和写入glossary.py#L484-L497def _assemble_term_content(self, name, description, synonyms) - str: content f{name} if synonyms: content f, {, .join(synonyms)} content f: {description} return content也就是说向量检索的输入文本形如Boogie Nights, BN Hotel, The Boogie, Boogie Hotel: Our luxury beachfront hotel located in Miami。同义词会参与向量化这正是用户说 The Boogie 也能命中 Boogie Nights的底层原因。术语 ID 默认由xxh3_checksum(f{name}{description}{synonyms})派生因此相同内容的术语 ID 是确定性的除非显式传入自定义id。3.2 语义检索find_relevant_termsGlossaryStore.find_relevant_terms(query, available_terms, max_terms20)是词表检索的核心抽象glossary.py#L111-L117。其实现要点若候选术语数量不超过max_terms直接全部返回跳过向量检索否则用query_chunks()将查询切块对每个块执行find_similar_documents(..., kmax_terms)带hints{tag: glossary_terms}提示合并去重后按向量距离distance升序排序取前max_terms个返回。默认上限为 20 个术语。当词表规模不大时全部术语都会进入上下文规模更大时只有与当前对话最相关的术语会被选中注入提示词。四、Agent 如何使用词表两个用途 源码链路官方文档指出词表在 Agent 交互中承担两个关键用途理解客户当客人说 Id like to stay at The Boogie 时Agent 知道这指的是你的酒店正确解释 Guideline当 Guideline 的 condition/action 引用了领域术语时Agent 需要靠词表理解其含义。4.1 词表驱动 Guideline 匹配的典型配置文档中的完整示例await agent.create_guideline( conditionthe user asks about Ocean View rooms, actionexplain the Sunrise Package benefits, ) await agent.create_term( nameOcean View, descriptionOur premium rooms on floors 15-20 facing the Atlantic, synonyms[seaside rooms, beach view], ) await agent.create_term( nameSunrise Package, descriptionComplimentary breakfast and early check-in for Ocean View bookings, synonyms[morning special, sunrise special], )在此配置下condition 与 action 都依赖 Agent 理解这些术语。当客户说Customer:I heard you have some rooms with a view to the Atlantic. What are those?客户既没提 Ocean View 也没提 beach view只说了 a view to the Atlantic。但基于词表中Ocean View的定义facing the AtlanticAgent 可以判定 conditionthe user asks about Ocean View rooms已满足进而执行 actionexplain the Sunrise Package benefits。4.2 源码链路从消息到提示词上述靠定义而非字面量匹配术语的能力在引擎中由一条清晰的调用链支撑第一步构建检索查询。每轮处理时引擎调用_load_glossary_terms(context)engine.py#L1864把当前上下文拼成一个语义查询上下文变量context variablesJSON 化当前交互事件客户消息等已加载 Guideline 的条件/动作文本When {condition}, then {action}已产生的工具事件数据tool events。然后交给find_glossary_terms_for_context()做向量检索。注意 Guideline 文本本身也参与查询——这正是Agent 根据 Guideline 内容反向召回相关术语的实现即使客户还没提到某术语只要 Guideline 引用了它对应术语也可能被召回进上下文。第二步多次刷新防止术语漏配。引擎不仅在首轮加载词表还会在 Guideline 匹配后和工具调用返回后各刷新一次engine.py#L646-L648、engine.py#L699-L701# Matched guidelines may use glossary terms, so we need to ground our # prompt with any glossary terms the guidelines may reference. context.state.glossary_terms.update(await self._load_glossary_terms(context))# Tool calls may have returned with data that uses glossary terms, # so we need to ground our prompt with any glossary terms the tools may reference. context.state.glossary_terms.update(await self._load_glossary_terms(context))这对应文档中静态知识 动态数据的衔接工具返回的数据里若包含领域术语也会被二次召回并注入后续提示词。第三步注入提示词。召回的术语最终通过PromptBuilder.add_glossary()写入系统提示词的 GLOSSARY 段prompt_builder.py#L403-L425模板原文如下The following is a glossary of the business. Understanding these terms, as they apply to the business, is critical for your task. When encountering any of these terms, prioritize the interpretation provided here over any definitions you may already know. Please be tolerant of possible typos by the user with regards to these terms, and let the user know if/when you assume they meant a term by their typo: ### {terms_string} ###这段模板透露了两个值得注意的工程设计定义优先级明确指示 LLM 对术语优先采用此处给出的解释覆盖你已知的任何定义——这是压制 LLM 通用常识、实现领域语义接管的关键指令容错与透明要求 LLM 对用户可能的拼写错误保持宽容并在做出我理解你指的是 X的假设时主动告知用户。同时生成秘密性规则要求 Agent 不得向客户暴露glossary、guidelines 等内部机制的存在见 canned_response_generator.py#L1448glossary.feature 中就有专门场景验证这一点Scenario: The agent explains term without exposing the glossary itself Given the term token defined as a digital token And a customer message, what is a token? When processing is triggered Then a single message event is emitted And the message contains an explanation about what a token is, without mentioning that it appears in a glossary五、测试证据词表能力的可验证行为BDD 场景文件 系统性地验证了文档所述的两类用途值得作为回归基线阅读歧义术语解释客户理解分别定义了token数字代币、wallet数字钱包、mining加密货币挖矿、private key、gas以太坊费用等极易歧义的词验证客户直接询问时 Agent 按词表定义回答Guideline 按术语名/定义触发Guideline 解释Scenario: The agent follows a guideline that mentions a term by name Given the term walnut defined as the name of an altcoin And a guideline to say Keep your private key secure when the customer asks how to protect their walnuts And a customer message, How do you keep walnuts secure? ... Scenario: The agent follows a guideline that refers to a terms definition Given the term walnut defined as the name of an altcoin And a guideline to say Keep your private key secure when the customer asks how to protect their financial assets And a customer message, How do I protect my walnuts? ...前一个场景中 Guideline 直接引用术语名 walnut后一个场景中 Guideline 引用的是术语的定义financial assets ↔ altcoin两个场景都应命中——这正是词表定义级匹配能力的双向验证从 Guideline / Tool 内容召回术语场景 The agent responds with a term retrieved from guideline content 中故意放入 50 个干扰术语验证引擎能基于 Guideline 文本召回正确的 leafwalnut 币的加密钱包工具场景则验证从 tool 返回内容中召回术语。SDK 层的持久化正确性含自定义 ID则由 tests/sdk/test_glossary.py 覆盖。六、词表 vs Guideline vs Agent Description文档明确三者的分工这是设计 Agent 时最容易混淆的地方Glossary 教 Agent事物是什么。例如A Club Member is a guest who has stayed with us more than 5 times. 术语数量不设限Guidelines 教 Agent在情境中如何行动。例如When speaking with Club Members, acknowledge their loyalty status. 数量同样不设限Agent Description 提供整体语境与个性。例如You are a helpful hotel booking assistant for Boogie Nights. 它是静态且有限的。可以这样理解词表构建 Agent 的词汇量Guidelines 塑造其行为Agent Description 设定其整体语境、角色、个性与语气。把定义写进 Description 会挤占有限的静态空间且无法参与语义检索把行为写进词表则会失去 Guideline 的条件-动作执行机制。七、词表 vs 工具静态知识与动态数据的分界词表术语和工具都能帮助 Agent 理解你的领域但目的根本不同词表提供静态知识工具提供动态数据访问。以酒店预订为例词表术语字段值TermClub MemberDescriptionA guest who has stayed with us more than 5 timesSynonymsloyal guest, regular guest对应工具check_member_status(user_id) # Returns current stay count and benefits词表术语提供Club Member 是什么的一致定义而工具能查询某个具体用户在你数据库中的实际状态。同理词表术语字段值TermOcean View RoomDescriptionPremium rooms on floors 15-20 facing the AtlanticSynonymsseaside room, beach view对应工具check_room_availability(room_type, dates) # Returns current availability and rates词表帮助 Agent 理解 Ocean View Room 是什么工具则提供具体房型实时的可用性与时价。这种静态知识词表与动态数据访问工具的分离能构建出清晰、可维护的 Agent 实现通用问询由词表兜底理解数据驱动的具体交互交给工具。从源码视角看两者在引擎中是互补而非竞争关系——工具事件数据会反过来参与词表检索查询第四节的第二步形成工具返回值里的术语 → 词表解释 → 提示词的闭环。八、实践建议小结为每个高歧义业务实体建术语酒店名、房型、套餐名、会员等级等且尽量多给同义词同义词参与向量化直接提升召回率Guideline 引用术语时用定义 术语名双通道表述如 BDD 测试所示词表同时支持按名称和按定义触发 Guideline条件文本写得越贴近客户实际措辞匹配越稳控制术语规模以适配 20 个的默认召回上限find_relevant_terms默认max_terms20术语总量过多时只有语义最相关的会进入提示词与核心业务无关的长尾术语可考虑按 Agent 标签拆分作用域定义与行为、实时数据各归其位定义进词表情境行为进 Guideline实时查询进工具三者不互相替代。【免费下载链接】parlantBuild reliable customer-facing AI agents with Parlant: an interaction control harness optimized for controlled, consistent, and predictable LLM interactions.项目地址: https://gitcode.com/GitHub_Trending/pa/parlant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考