引导工具使得代理式RAG需要执行三步操作，而非仅通过一次复杂的调用即可完成。

重要性摘要、子句差异以及计数验证在可调用的引导工具、工具搜索以及不完整的返回结果未向模型传授该序列之前，始终处于静止状态。

发布者：REACTAPP.TOP加入本站 2026年9月26日阅读约 28 分钟6538 词

来源: Reflections on Tools: Getting Agentic RAG to Take Three Steps-Part 7 of my EDGAR Intelligence MCP journey

本系列的前几部分构建了摘要树，将原始数据与语言模型分开，从图表中提取文本，分析不同申报版本之间的变化，探讨信息是如何被检索到的，以及查询对应的是哪家公司。这一部分则聚焦于这些组件实际所能触及的有限界面：模型在做出决策前会扫描的一段简短的工具描述文本。

三种工具

第四部分分析了风险因素的年度变化情况。将两份10-K文件输入模型并询问哪些方面发生了变化，这种方法不仅成本高昂：Chroma的Context Rot技术固定了任务结构，仅在多个模型中改变输入长度——随着上下文变长，性能会以无法仅通过任务本身预测的不均匀方式下降。这种方法的失败是隐性的：一个报告出六处变化的模型永远不会告诉你它还遗漏了第七处变化。仅依靠字符级的标记就难以应对文本重排问题，双重总结的情况更糟。那些成功的方法使用了三种工具，而非两种：

L1用于识别重要内容——采用RAPTOR风格的章节总结方式（如第一部分所述，每个文件章节由一个AI生成的概要）。能指出哪些主题发生了变化，每侧只给出一个结论，能够捕捉到字符配对无法识别的含义。

证据差异对比——针对每个被标记的主题，以条款级别显示可引用的具体措辞。完全自动化处理，覆盖全面且可审核。

验证计数功能——检查两份文档中的独特措辞是否确实存在差异。若双方使用相同表述，通常只是顺序调整，并非真正变化。

那个三要素结构依然正确。但作为文章段落来写时，它却完全毫无作用——其中没有任何内容能触发相应工具的运行。那个询问苹果公司风险因素有何变化的模型从未读过这篇文章，它只有问题、工具列表以及这些工具自身描述的文字。看到diff_filings时，它的合理反应是调用它并描述返回结果。代理型RAG往往忽略了这一点：信息检索只是容易的部分，真正困难的是仅凭工具附带的文本就教会模型该按哪三个步骤以及何种顺序操作。

_SECTION_SLUGS = (
    "overview", "routing", "setup", "deal_walkthrough", "diff_workflow",
    "tools", "warmth", "time_axes", "sql_track", "metrics", "alpha", "fields",
    "idempotency", "presentation", "response_bounds",
)


def _split_sections() -> dict[str, str]:
    parts = _GUIDANCE_MD.split("\n## ")[1:]
    assert len(parts) == len(_SECTION_SLUGS), (
        f"guidance has {len(parts)} sections, {len(_SECTION_SLUGS)} slugs"
    )

如果指导信息有误，这些工具就永远无法协同工作；即便指导正确但未被阅读，它们同样无法协同。本文的其余部分将探讨如何让这些指导信息顺利加载、保持简洁，并在工具搜索中存活下来。

选择、调用以及那介于两者之间的事物

工具的使用过程可划分为人们早已熟悉的两个阶段。

选择指的是决定当前轮次中哪些工具应被纳入活跃集合——包括路径规划、工具搜索以及目录筛选等。而调用则是在工具可用后，以结构化方式传递参数并发起请求。框架与模型API都非常重视这两个环节。

还存在第三个既不属于选择也不属于调用的阶段：定位——即通过文字说明告诉模型某个工具在工作流中存在的原因、使用该工具之前必须完成什么步骤，以及使用完成后“任务完成”的状态应为何样。定位并非检索或生成的选择题，而是将三个独立的工具转化为有序执行序列的关键语句。

大多数工具会将操作指引隐藏在不断变长的系统提示中，或者干脆省略这些指引，指望工具名称就能让用户明白用法。当拥有数十个MCP工具且用户只提出关于两份文档的一行问题时，这两种方式都难以应对。

指引工具

指引工具是一种专门用于提供操作流程的工具：即对多步骤方法的简短且权威的描述。它不会获取文档内容，也不会计算差异，只会返回模型在后续几轮对话中应遵循的文本。

For the full repeatable diff flow see `edgar_guidance(section="diff_workflow")`.

与在每个系统提示中都塞入完整操作流程相比，使用这类工具的成本更低。同时它也便于查找：当查询内容涉及“哪些内容发生了变化”时，工具搜索就能找到它；而如果用户只需一个数字信息，则不会显示该工具。

当指导工具变成会随时间变化的文档副本，或是试图自行进行信息检索时，它们就会失效。应保持其内容为简短的流程说明。

技能文件会指出方向，而非直接复制内容。

技能文件（或技能包、智能体操作手册）应注明指导工具的名称与用途，而非直接粘贴其内容。复制会导致出现两个不同的信息来源。一旦方法发生变化——比如新增验证步骤或计数规则——只需更新一次指导工具即可。而技能文件会持续提示“在年度风险因素发生变化时，首先调用workflow_guidance”。

For document selection and extraction strategies, use PFW_get_guidance
(see quick reference chart for section selection).

For document selection strategies and multi-document workflows, use
PFW_get_guidance (see quick reference chart for section selection).

For cross-MCP workflows, use PFW_get_guidance (see quick reference chart).

For field selection guidance and token estimates, use
PFW_get_guidance(section='tools').

这种间接方式起初会让人觉得繁琐，直到你解决了某个隐性故障，才发现原本有十二个技能文件其实是错误的副本。

USPTO MCP服务器关于指导工具的启示

美国专利商标局早前的MCP项目在另一个领域犯了同样的错误：工具太多，每个工具都有友好的名称，却没有统一的排序规则。工作人员会优先使用那些界面好看的检索工具，从而跳过验证步骤。解决办法并非增加更多工具，而是在工具返回的结果中明确指出哪些顺序是必须遵循的，以及哪些结果需要进一步核实才能完成。

WORKFLOW: even the substantive-only headline is clause-level and can
still be noisy on a heavily rewritten section. For "what materially
changed" questions, run RAPTOR L1 FIRST — search_filings(level=1,
section_path=<the section>) on each filing to read the two section
summaries and build a short topic list (typically 5-10 items) of what
actually moved. Then call this diff to pin the EXACT clause language
for each flagged topic, and skip every pair that doesn't touch one.
The L1 contrast also surfaces meaning that a cold diff buries in
reflow (e.g. a new tax-law valuation allowance). See
edgar_guidance(section="diff_workflow") for the full repeatable flow.

这些经验也被应用到了EDGAR项目中：

指导说明必须能够被直接调用，而不能仅记录在模型根本看不到的README文件中。
指导说明必须足够简短，以便在工具搜索后出现其他描述信息时仍能保持其有效性。
指导说明在提及成功路径的同时，也必须以相同的方式列出失败模式（例如“到达红线后不得停止”）。

指导内容必须由对应领域所有者掌控——USPTO的序列信息不应出现在EDGAR工具的文本中，反之亦然。

因此工作流程被移至文档字符串中

将方法放在人类易于理解的Markdown文件中对模型没有任何帮助；而将其放入指导工具的工具文档字符串/描述中则有效，因为这是运行时在选择该工具时会注入的文本。

- `alpha` (default = EDGAR_RAPTOR_HYBRID_ALPHA, falling back to
  EDGAR_HYBRID_ALPHA): only affects the L0 clause collection, which
  carries BM25 sparse vectors. 1.0 = pure dense, 0.0 = pure BM25. Do
  NOT lower it for an exact citation or identifier (a literal
  "$750,000,000", a defined term, "Section 9.1(d)") — keep the default
  and pass `rerank=True`, which supplies most of the precision on a
  short identifier-only query.

实际迁移过程如下：提取文章中关于三种工具的段落，将其压缩为具体的操作步骤，附加成功标准，然后作为get_yoy_risk_factor_method（名称可能不同）的返回值呈现。技能提示和系统指令仅指向该工具。当第四部分的方法增加了计数验证步骤时，只有指导内容的返回值会发生变化。

文档字符串并非小说的倾倒场。应撰写几百字的流程描述，而非整篇文章。为人类用户提供链接参考；同时保持可调用接口的简洁性。

返回路径：句子的后半部分

如果某个工具仅给出大量修改提示却未说明下一步该做什么，就会让模型习惯于直接总结并停止处理。返回路径实际上是句子的后半部分：在收到证据后，由哪个工具进行确认、哪个工具进行计数，以及何时可以给出答案。

- For a MULTI-YEAR or HISTORICAL question about one company, prefer
  `group=` over a single `cik`: a kind='lineage' group covers the
  whole predecessor/successor chain (so a question that crosses a
  name/CIK change — Avago→Broadcom, Apollo's predecessor — doesn't
  silently miss the older filings) and its members COLLAPSE into one
  issuer block, with each hit keeping its own cik and the block
  carrying `lineage_ciks` for provenance. `resolve_parties_to_cik`
  reports which group to pass.

在多步骤工作流中，设计时应让工具返回部分结果以及下一步的提示。这并不意味着该工具本身就要变成一个智能体——只是意味着在验证尚未完成时，返回的内容不应看起来像是一个完整的答案。此外，错误反馈应区分“未发现偏差”与“无法执行差异对比”，否则模型就会凭空捏造置信度。

相同的机制，不同的工作流程

引导工具并非仅用于风险因素变更场景。在公司决议处理（第6部分）、图表提取（第3部分）以及数值安全型摘要生成（第2部分）中，当用户问题描述不完整时，都需要一个可调用的简短方法。其模式始终如一：每个工作流程系列对应一种引导工具，这些工具具备明确的触发条件，且不会过早判定任务已完成。

AI-RANKED RESULTS — ordered by semantic similarity, not authority. L0 hits
are extracted clause text. L1/L2 hits are AI-generated summaries — take
especial caution with figures ... A claim about WHAT CHANGED, read off two
L1/L2 summaries, is likewise unverified until the distinguishing language
is confirmed against the underlying clause text on both sides.

在多个工作流程之间共享同一个大型引导模块会再次引发系统提示模块的问题。建议使用多个小型引导工具，为其描述添加清晰的触发条件说明，以便通过工具搜索找到合适的工具。

以及用于启动整个流程的工具

某些任务在开始检索之前需要一次引导式咨询：确定是哪家公司、使用哪些表格、涉及哪几年以及仪器的排序方式。如果没有这一步，处理人员就会错误地针对不匹配的文档对使用diff_filings功能。

INTERPRETING THE REDLINE — you can and should tell real edits from chunking
artifacts; do that filtering rather than treating every delta as substantive.
... The word-level highlights are the tell: differences only at the START
and/or END of the clause (or a small leading/trailing add/delete) mean a
realignment, while a term changing in the MIDDLE (amounts, dates, defined
terms, added/removed obligations or conditions) is a real edit.

引导式咨询可以通过聊天渠道提出澄清问题，但仍然禁止过早使用各种工具功能。该流程需具备幂等性——重复调用不应改变存储状态。

三十五种工具

EDGAR MCP平台上的工具数量已增长到约三十五种。在如此庞大的规模下，不可能将所有工具的描述都放入提示词中，而且让模型直接看到完整列表会导致随机选择。因此必须进行工具搜索：将查询嵌入到工具元数据中，提供候选列表，再让模型自行选择。

if counts.get("substantive_modified"):
    response["chunking_note"] = AI_DIFF_REALIGNMENT_NOTE

35这个数字并不重要——关键在于指导工具必须能够通过搜索被找到。如果该工具的描述与“变化内容/同比变化/风险因素”不符，它就永远无法进入候选名单，于是那三种工具又会再次失去作用。

工具搜索与三种工具

对于同比风险因素分析流程，搜索结果应优先包含：指导工具、L1显著性工具、差异分析工具以及计数/验证工具。对于这类问题而言，其他所有内容都属于干扰信息。

"revenue is a derived metric — one issuer's consolidated number.
 A multi-CIK `ciks=` list would blend inputs across issuers into a
 figure belonging to none of them. Call once per `cik=` (or pass a
 lineage `group=` for a predecessor chain)."

优化搜索功能属于产品开发工作：需要处理描述中的同义词、负面示例（如“不适用于单公司查询”），以及包含预期首选工具的用户问题评估集。没有这样的评估机制，指导功能就只能停留在理论层面的偏好而已。

用户所见内容

用户不应看到底层结构。他们提出简单问题，就能得到带有引用来源的答案。在下方，记录中可能会显示“指导→L1→差异对比→数量”等信息。产品用户界面可以将这些内容整合为进度标签（如“正在检查哪些内容发生了变化”、“正在提取精确条款”、“正在验证新颖性”），而无需暴露工具名称。

Input(s) [...] were not tagged by this issuer under any recognized XBRL
concept in the requested periods, so the derived value is 'unknown'
wherever they are needed. Not every issuer reports every line item
(e.g. asset-light filers omit capex), so the same metric may resolve
for an issuer that does tag them.

当出现故障时，应显示出问题发生的阶段。“差异对比不可用”这一提示具有可操作性，而“智能体出错”则没有。

代理页面

面向用户的代理页面为操作员和审核员记录相同的工作流程。这类页面可以很长，但绝不能成为模型所需方法的唯一来源——因为除非你特意设计相关功能，否则模型在运行过程中不会浏览你的文档网站。

Per-figure descriptions are NOT produced on this path: charts and images
on these pages carry no annotation, and their absence is not evidence the
page had no figures ... check the linked source image (source_url) before
concluding something is absent from the filing.

请确保代理页面与指导工具之间保持关联：页面上写着“标准操作步骤位于工具X中”，而工具描述则说明“相关说明在URL Y处”。二者内容出现偏差即属于发布缺陷。

自行复现

若要在本系列之外复现该问题模式：

以指令式步骤的形式编写方法，明确指定使用的工具及停止条件。
将其作为指导工具的返回内容进行输出。
让技能模块指向该工具，而非直接粘贴返回内容。
让证据收集工具在验证运行完成前始终声明数据不完整。
在庞大的工具目录前添加工具搜索功能，并通过标准问题集来评估首个工具的准确性。
将人工文档作为代理资料，而非运行时的真实数据来源。

armth: hits from filings whose summary tree is still cold (L0-only)
trigger background tree builds — `tree_builds_enqueued` in the result
says how many; re-run the search shortly after to get L1/L2 summaries.

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

EXPECTED_NON_DEFERRED = {
    "guidance.py",
    "resolve_parties.py",
    "edgar_strategic_search.py",
}

# Anthropic's stated range for non-deferred tools.
MAX_NON_DEFERRED = 5

该方法即将发生变化

第四部分的三个要点并非最终定论。新的验证技巧、更便宜的显著性模型、更好的重排处理方式——这些都将相继出现。如果这种方法仅存在于论文和技能展示中，那么每一次改进都将成为一个需要多文件参与的考古项目。而当它存在于某个指导工具中时，改变只需一次编辑，再对核心问题进行回归测试即可。

Use your tool-search or tool-discovery step, but do not CALL any of the
tools it finds. I want to read them, not run them.

1. Search for tools now, by server name and by keyword, and list the MCP
   servers and tools you can reach. If your first look says you have no
   tools, search again before concluding that: with tool search enabled,
   most tools stay hidden until you go looking for them.

2. Pick one non-trivial tool. Show me, verbatim and without summarising
   or reformatting:
   - its exact tool name
   - its complete description text, every line of it
   - its full input schema: each parameter, its type, its default, and
     the description attached to that parameter

   Print the description IN FULL even if it runs to a thousand words or
   more. Do not abbreviate it, do not list its section headings instead,
   and do not tell me to look at the tool result: I cannot see what you
   can see, which is the whole point of this.

3. Then tell me, in your own words:
   - does that text instruct you to call anything BEFORE this tool, or
     AFTER it?
   - does it tell you how to interpret or filter the result?
   - does it tell you to relay anything to me?
   - is there anything in it you would not have done on your own?

要点总结

代理型RAG并非“先检索再生成”。在检测SEC文件中的变更时，它实际上是一个组合式的工具链，只有当模型在能够实际读取的位置被告知应遵循的顺序时，该工具链才能正确运行。这三种工具（显著性摘要、条款差异对比、计数验证）用于解决第4部分中的科学问题。在可调用的指导工具、以指向而非复制的方式传递技能、拒绝过早判定任务完成，以及工具搜索能在数十个同类工具中找到相应指导之前，这些工具都不会发挥作用。

如果你愿意，可以将选择与调用视为已解决的基础要素；真正的区别在于第三重要素：定位。仅存在于README中的定位只是装饰性内容，而存在于系统提示中的定位则会变成难以维护的混乱结构，唯有那些存在于简短、可搜索且由相关领域管理的指导工具中的定位才是真正具备操作性的。

USPTO的MCP项目在商标与专利领域也给出了同样的教训：没有顺序标识的友好工具名称会导致人们一开始就犯错。EDGAR项目继承了这一问题，特意将工作流程转移到了文档字符串中。35种工具的出现使得工具搜索成为必要环节；搜索让描述的质量成为正确性的体现，而非营销用语。

用户看到的内容应保持简洁冷静。代理页面显示的内容应完整无缺。模型在首次实际检索前读取的内容应简短明了，并需标注所使用的方法版本。若明日方法有所变更，便需更新指导工具并重新运行那些关键问题，切勿执着于十二个重复的副本。

若要从这部分内容中记住一条工程原则：绝不能让多步骤方法的唯一副本存放在模型无法调用的地方。文章用于教导人类，指导工具则用于训练智能体，技能只是指引方向的手指，而返回结果往往是需要后续动作的半句话。工具搜索则是决定这些文本能否进入处理流程的关键关卡。

这一系列仍在持续：工具不断进化，目录日益扩充，而指导内容必须始终是关于这些工具如何组合的最简洁准确的描述。正因如此，代理式RAG采用三步法而非一次性炫目的操作。

新工作流系列的具体检查清单：

为工具命名，并设计能让隐性故障更难发生的验证机制。
编写描述与用户提问方式相匹配的指导工具。
确保返回的内容不超过几百字的操作说明。
要求用户运用自身技能，禁止直接复制粘贴。
若无验证则将返回的证据标记为不完整。
设置必须由首个工具提供指导的“关键问题”。
链接人工辅助页面，但不要使其成为运行时的必需项。
将方法变更演练为单工具编辑操作。

那些跳过检查清单的团队会以痛苦的方式重新发现“上下文失效”问题：模型虽然“读”了所有文件并能流畅回答，却忽略了那些至关重要的变化。而遵循检查清单的团队则会发现，基于代理的RAG系统在最好的意义上显得乏味——步骤可预测、引用内容明确，且验证结果能够确定无误。

乏味正是目标。那些华而不实、仅依赖单一工具的答案，其实不过是将错误悄无声息地传递给用户罢了。

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

Use it over numbers you ALREADY retrieved (e.g. from
query_financial_facts) — it does NOT fetch data. Supports + - * / // % **,
unary minus, and abs, round, min, max, pow, sqrt, log (natural), log10,
log2, exp, floor, ceil, plus constants pi and e. No variables, attribute
access, or other calls (safe AST evaluator).

Examples:
- 5-yr revenue CAGR: "(60922/26974)**(1/5) - 1"
- net debt / EBITDA: "(96700 - 29943) / 34000"
- YoY % change: "(383285 - 394328) / 394328 * 100"
- segment as % of total: "23056 / 81462 * 100"

Returns {expression, result, formatted} on success, or {error, expression}
if the expression is rejected.

参考资料

本部分的主要参考资料包括作为背景的ReAct与工具使用相关研究、用于证明长度衰减现象的Chroma的Context Rot研究、第一部分中使用的RAPTOR风格总结方法、本EDGAR Intelligence MCP系列之前的章节中关于L1/diff/count工具的内容，以及该项目自身的MCP工具目录和代理文档。软件包与API名称会不断变化——应将指导性文本视为描述智能体行为的版本化契约，而将人类撰写的文章视为评论而非运行时的真实依据。

为何静态方法在页面上看起来已完成实现

技术文档写作需要详尽的说明。那些提到L1、diff以及计数功能的段落，读起来就像设计文档。而实际使用工具的人并不阅读设计文档，他们只在有限的资源约束下阅读工具相关的说明文本。正是由于这两类读者的差异，大多数所谓的“面向代理的”演示最终都变成了单一工具的包装壳。要缩小这一差距，就必须接受这样一个事实：你最出色的散文部分可能需要被重写为可调用的程序代码，而且这类程序代码的简洁度本可以低于原文散文。

定向性与检索质量

优化嵌入模型、分块处理以及重新排序功能有助于提升证据分析工具的性能。但这并不会要求模型必须按顺序调用这三个功能。团队通常会花费四分之一的时间优化检索指标，再花一周时间处理提示词，之后仍会疑惑为何变化检测功能仍然只依赖一次diff_filings调用。应将预算规划视为首要工作流程：包括描述文本、搜索同义词、黄金标准的首选工具测试以及结果格式审查。

值得记录的失败案例

把那些已经造成损失的失败情况记录下来：在仅显示排版调整的警示后就停止操作；轻信能消除矛盾的双重总结；将内容重组视为新内容；在公司内部决议尚未完成时就给出答复；将美国专利商标局的流程混入EDGAR系统操作中。每一次失败都会成为指导方针中的一条重要准则，同时也对应一个关键问题——若忽视了这条准则，该问题就会出现。

指导内容的代币经济模型

长度为300字的指导回复比“以防万一”而插入两份10-K报告更经济，也优于列出所有工作流程的系统提示。此外，它还比不断给出错误答案所带来的支持成本更低。评估指导内容时应采用与检索相同的标准：延迟时间、工具搜索的命中率以及后续验证通过率——而不仅仅是文本是否显得聪明。

治理机制

谁有权限编辑指导工具？应将其视同生产配置进行管理。需经过审核、保留历史记录，并禁止在不更新核心问题情况下更改指导内容的合并操作。查看代理页面的操作员应能看到与工具在标题行中返回的相同版本标识。当审计人员询问为何智能体调用了三个工具时，应指向经过版本控制的指导内容——而非上个月在Slack上的讨论记录。

不应放入指导内容中的信息

不要存放机密信息、包含凭证的环境URL或用户特定状态。不要放入完整的文件摘录。也不要存放篇幅庞大的分支式策略。但必须包含执行顺序、停止条件以及下一个工具的名称。如果某些细节仅供人类查看，应将其留在代理页面上。

与LangGraph风格图谱的关系

有些团队将这三个步骤编码为固定结构的图谱，不考虑模型选择。这种做法是可行的，且通常更安全。当面对描述不足的问题时，虽然仍希望借助模型来解决，但又需要让该方法在众多工具中易于被查找时，引导工具就能发挥作用。图谱与引导工具相辅相成：选定方法后可以用图谱来实现它；而引导工具则有助于方法的选取，并确保混合智能体保持诚实。

评估框架概要

维护一个表格，记录用户问题、预期的首个工具、预期的工具序列类别以及禁止提前终止使用的工具。每次对指导内容进行修改后都要运行该框架。如果首个工具的准确率下降，则构建失败。每周抽查转录内容，确保回答流畅且未跳过计数步骤。发布一个简单的仪表板，以便产品团队和工程团队对“智能体执行了三步操作”这一概念有统一的理解。

命名规范

工具名称应符合搜索需求：用户输入的动词（如explain_yoy_risk_factor_method）比那些巧妙设计的内部代号更实用。描述中应包含同义词：变化、差异、同比、风险因素、1A项、与去年相比等。负面提示也有帮助：“不适用于实时股票报价”，“不适用于单段总结”。

扩展到多个系列

一旦多个领域都拥有指导工具，就可以建立一个简单的元索引：域名→指导工具名称。切勿将不同领域的工具合并为同一个工具。跨领域污染正是导致美国专利商标局的建议泄露到EDGAR系统中的原因。该索引应保持简洁明了。

第四部分：闭环总结

第四部分阐明了为何单一工具在科学层面是不够的。本部分则说明了为何即便拥有正确的科学方法，若没有可用的指导界面，在实际操作中依然会失败。应将这两部分结合来看：缺乏指导的工具毫无作用；仅有指导而无工具则只是表面文章。唯有二者结合，代理型RAG才能在要求必须给出回应的任务中获得“代理型”这一称号。

操作附录：演练脚本

在发布指导内容变更之前，先进行一次演练：进行冷启动测试、提出关键问题，确认指导内容是首选工具，确认两侧均能运行L1系统，确认已要求针对指定配对指导内容进行差异对比，确认计数功能正常运行，同时确认用户可见的答案会引用相关条款并说明验证情况。在指导内容版本旁记录转录ID。如果有任何步骤被跳过，那么在庆祝检索指标达标之前必须先修正相关描述或搜索设置。

操作附录：演练脚本

在发布指导内容变更之前，先进行一次演练：进行冷启动测试、提出关键问题，确认指导内容是首选工具，确认两侧均能运行L1系统，确认已要求针对指定配对指导内容进行差异对比，确认计数功能正常运行，同时确认用户可见的答案会引用相关条款并说明验证情况。在指导内容版本旁记录转录ID。如果有任何步骤被跳过，必须在庆祝检索指标达标之前修正相关描述或搜索设置。

操作附录：演练脚本

在发布指导内容变更之前，先进行一次模拟测试：进行冷启动测试、提出关键问题，确认指导内容是首选工具，确认两侧均能运行L1系统，确认已要求针对带名称的配对指导内容进行差异对比，确认运行次数统计正确，确认用户可见的答案会引用相关条款并说明验证情况。在指导内容版本旁记录转录ID。如果有任何步骤被跳过，必须在庆祝检索指标达标之前修正相关描述或搜索设置。

操作附录：模拟测试脚本

操作附录：演练脚本

在发布指导内容变更之前，先进行一次模拟测试：进行冷启动测试、提出关键问题，确认指导内容是首选工具，确认两侧系统均能运行L1功能，确认已要求针对带名称的配对指导内容进行差异对比，确认运行次数统计正确，确认用户可见的答案中引用了相关条款并说明了验证情况。在指导内容版本旁记录转录ID。如果有任何步骤被跳过，必须在庆祝检索指标达标之前修正相关描述或搜索设置。

操作附录：模拟测试脚本

操作附录：演练脚本

在发布指导规则变更之前，先进行一次模拟测试：进行冷启动测试、提出关键问题，确认指导规则是首选工具，确认两侧都能运行L1模型，确认会要求提供带有明确名称的配对指导规则，并记录运行次数，同时确保用户可见的答案能引用相关条款并说明验证情况。在指导规则版本旁记录转录ID。如果有任何步骤被跳过，必须在庆祝检索指标提升之前修正相关描述或搜索设置。

← 全部文章发送简报