Doubao Enterprise Search

读取要求：必须完整读取本 Skill 后再执行任何路由或工具调用。若单次读取被截断，必须分段继续读取；只有看到文末唯一标识 【全文读取完成】 才算读完，此前禁止进行任何路由判断或工具调用。

doubao-enterprise-search（企业搜索）

必读摘要（先读这里）

必须全文通读本 skill；摘要只用于防止遗漏关键规则，不能替代正文。尾部有重要信息，禁止中途截断。

1. 每个用户问题默认只调用一次 enterprise_agentic_search；多个内部子问题应合并调用。query 必须是完整、可独立理解的自然语言问题，禁止关键词、标签或名词枚举。仅在出现新目标、新线索或有限候选未覆盖时补查，且不得重复已覆盖范围。详见第 2 章。
2. 内容总结、讨论复盘、结论 / 待办 / 风险 / 进展提炼等信息整合类需求，优先调用 enterprise_agentic_search 工具；读取、查看、总结、编辑、导出明确对象本体或查询状态时，走对应 lark-xxx。详见第 1、5 章。
3. 显式 /doubao-enterprise-search 入口下，未命中明确对象操作、明确公开来源、本地文件 / CLI 等反向信号时，边界不清倾向调用 enterprise_agentic_search 工具。详见第 1 章。
4. 同一轮同时包含“内部资料查询 / 复盘 / 总结 / 结论提炼 + 写入 / 编辑 / 发送 / 导出明确对象”等后处理时，先完成内部资料查询，再处理对象操作。详见第 5 章。
5. 使用 enterprise_agentic_search 工具结果时，每条工具来源的事实、数据、结论或转述都必须就地添加对应来源引用，并保留来源链接和材料入口链接；Markdown 材料链接必须原样迁移。详见第 4 章。
6. enterprise_agentic_search 工具无结果或结果不足时，不要断言事实不存在；用户未排除公开来源时，可以补充公开信息，并区分内部资料和公开来源。详见第 4 章。

0. 定位与工具说明

本 skill 负责 enterprise_agentic_search 的进入判断、调用边界、query 构造、多轮继承、无结果兜底和结果使用要求。它处理的是企业内部知识搜索、追溯、复盘、汇总、口径查询和跨来源综合的边界。

一句话区分：用户是想“从企业内部资料里找答案并综合”，还是已经“锁定了某个具体对象，要读取、编辑或操作它”？

• 找答案、查背景、追溯讨论、汇总结论 → 进入本 skill 判断是否调用 enterprise_agentic_search 工具。
• 读/改/发/提交某个明确对象 → 不调用 enterprise_agentic_search 工具，走对应 lark-xxx。

enterprise_agentic_search 是什么

enterprise_agentic_search 是企业内部知识问答 / 推理整合工具，不是关键词搜索引擎。它会基于自然语言 query 理解用户意图，检索企业内部知识库，并从文档库、会议记录、工作消息、用户邮件、用户自建知识库等多来源返回相关内容和来源信息。它适合回答“飞书里 / 公司内 / 内部资料中有没有相关信息、结论、讨论、口径、背景”的问题，返回结构化参考信息或总结，最终回答仍需要结合上下文和来源完整性判断。

enterprise_agentic_search 不是什么

• 不是对象操作工具，不能替代文档读取、消息发送、审批提交、日程状态查询等 lark-xxx 能力。
• 不是公开网页搜索工具，公开信息、官网、新闻、电商、论文等应走公开信息工具。
• 不替代 CLI、本地文件处理或直接回答。

1. 路由判断：这个问题该不该调用 enterprise_agentic_search 工具

按以下步骤依次判断：

前置步骤：多轮上下文预处理

先检查第 3 章的多轮上下文（本轮是否承接上一轮唯一主题、是否发生来源切换），补全本轮意图和来源方向。注意：多轮预处理不直接决定调用 enterprise_agentic_search 工具，是否调用仍由后续步骤判断。

步骤 1：判断入口类型（见 1.1）

• 显式命令入口（/doubao-enterprise-search）→ 置信度高，边界不清时倾向调用。
• 语义召回入口 → 置信度低，边界不清时倾向不调用。

入口类型只对本轮生效。

步骤 2：检查硬性排除（见 1.2）

命中任一硬性排除场景 → 不调用 enterprise_agentic_search 工具，导流到正确路径。即使用户显式使用了 /doubao-enterprise-search 也不例外。

步骤 3：判断是否明确命中 enterprise_agentic_search 工具调用条件（见 1.3）

命中任一明确场景 → 调用 enterprise_agentic_search 工具。

步骤 4：边界不清时细判（见 1.4）

未命中步骤 2 也未命中步骤 3 → 按 1.4 节 7 条原则判断，并对照第 5 章“易混边界速查”确认是否命中高频混淆场景。

步骤 5：按入口类型决定默认倾向（见 1.5）

以上步骤仍无法确定 → 显式命令入口倾向调用，语义召回入口倾向不调用。

1.1 先判断入口类型

每次使用本 skill 时，先判断入口类型：

1. 显式命令入口：用户本轮消息以 /doubao-enterprise-search 开头。说明用户手动选择了企业搜索，本轮边界判断更积极：只要未命中硬性排除，边界不清时默认倾向调用 enterprise_agentic_search 工具。
2. 语义召回入口：用户没有显式命令，但系统 / 模型因问题可能涉及企业内部资料而加载本 skill。说明当前只是“可能需要企业内部搜索”，本轮边界判断更谨慎：只有问题核心明确或高度可能依赖企业内部资料、内部口径、内部系统或企业协作记录时，才调用 enterprise_agentic_search 工具。

入口类型只对本轮生效；后续轮次不继承“显式命令入口”的宽松边界，只能继承主题、来源方向和已确认约束。

1.2 硬性排除：命中即不调用 enterprise_agentic_search 工具

以下场景所有入口通用；即使用户显式使用 /doubao-enterprise-search，命中后也不调用 enterprise_agentic_search 工具，而应导流到正确路径。

硬性排除仅适用于用户意图明确不依赖企业内部资料的场景，不能仅凭 query 表面像公开知识或生活服务就排除。对于显式命令入口，即使 query 表面是通用知识、生活服务、行业规则、金融常识或外部信息，也不能仅凭 query 表面特征直接排除，必须按第 1.4 节细判后再按第 1.5 节默认倾向做决定：

• 用户要读取、查看、总结、编辑、创建、导出、提交、发送、撤回或查询明确对象本体 / 状态 / 字段 / 内容。明确对象包括 URL/token/ID，或上下文已唯一指向的对象，例如上文提到的文档/会议/邮件。
• 查询一个或多个人员的姓名、部门、职位、组织关系、通讯录中的团队归属、邮箱、收件人或其他通讯录字段，查询群成员 / 群人数 / 群成员列表等群对象属性，查询当前用户自己的明确日程、任务、邮件、考勤等单一系统实时记录，或执行发送 / 回复 / 点赞 / 群管理等消息操作。
• 用户明确要求公开信息、官网、新闻、公开报道、电商平台、社媒、论文、外部商业信息或生活服务，并明确不需要或排除了企业内部资料。
• 本地代码、CLI、文件处理、运行命令、环境排障。
• 用户已提供内容上的翻译、润色、改写、闲聊、普通代码生成，且不需要外部事实。
• 纯粹算术或单位换算等不依赖任何外部规则、专业口径、内部资料的计算。
• 用户明确说不要查内部、不要飞书、只查公开资料。

判断为误选时，不要直接失败，也不要强行调用 enterprise_agentic_search 工具。应简短说明原因并切到正确路径。

1.3 明确应调用 enterprise_agentic_search 工具的问题

以下场景应调用 enterprise_agentic_search 工具：

• 内部资料、概念与制度口径：明确查询企业内部资料、公司资料、内部文档、知识库、飞书 / Lark 内信息、历史讨论、内部沉淀、内部概念、内部术语、企业文化 / 价值观、制度流程、业务口径、当前口径、最新版本、申请方法、申请流程、入口路径、内部系统信息、HR / 福利 / 员工权益 / 出差 / 差旅 / 报销；不得凭模型记忆、旧知识或常识直接回答。
• 内部工具 / 产品 / 能力 how-to：询问“怎么 / 如何 / 在哪 / 入口 / 路径 / 流程 / 需要什么材料 / 申请方法 / 操作步骤”等信息获取问题，且对象属于或可能属于企业内部制度、内部工具、业务流程、产品能力、企业版能力、内测 / 灰度功能、使用入口、接入方式、平台端差异等。
• 企业归属语境：使用“我司 / 公司 / 组里 / team / BU / 我们组 / 项目组”等企业归属语境，且问题依赖内部事实、非公开资料、业务 / 项目背景、客户信息、历史决策依据或协作归属。
• 跨来源复盘与背景追溯：按主题、时间段、项目、团队、人员、群聊、会议等维度做搜索、追溯、来源定位、复盘、回顾、汇总，或查询背景、反馈、风险、结论、待办、进展、决策依据、历史沟通、协作记录。这类信息通常散落在文档、会议、消息、邮件等多个来源中。
• 数据口径与业务沉淀：查询内部产品、内部工具、业务数据口径、比例、数量、趋势、分布、覆盖率、客户 / 合作方关系、客户项目、实验 / 灰度 / 上线 / 放量、OKR、业务编号、业务指标等沉淀结论。
• 内外部能力对比与内部资源：外部产品 / 第三方功能 / 竞品资料与当前企业 / 组织自有、内部使用或可能属于当前企业 / 组织的产品、工具、能力、服务做对应关系、功能差异、口径、资料或对比；查询公司品牌、内部活动、品牌物料、员工内购、纪念品、周边、领取 / 购买渠道等内部资源时，默认按内部信息查询处理；只有用户明确限定官网、电商平台、公开售卖页或公开媒体信息时，才走公开搜索。

1.4 边界不清时的判断原则

本节只处理「未命中 1.2 硬性排除，也未命中 1.3 明确调用」的情况；显式入口和语义召回入口的默认倾向见 1.5。按以下检查项判断：

1. 先看用户是在查信息还是做操作：先区分用户是在获取规则、口径、背景、结论、风险、复盘、汇总，还是在执行读取、创建、编辑、提交、发送、撤回、导出、查询状态等对象操作。对象操作是反向信号，走对应 lark-xxx；信息获取是正向信号，继续判断是否调用 enterprise_agentic_search 工具。
2. 再看信息来源：
   • 内部资料 / 内部系统 / 内部口径 / 业务数据 / 协作记录 → 调用 enterprise_agentic_search 工具。
   • 明确公开来源或明确排除内部资料 → 公开搜索。
   • 内外混合 → 内部部分调用 enterprise_agentic_search 工具，公开部分使用公开信息工具，并区分来源；若内部查询对象、范围或候选名单依赖公开信息（如榜单 Top N、公开名单、官网清单、行业名单、公开材料中的对象），应先获取公开信息确定候选对象，再用 enterprise_agentic_search 查询这些对象的内部客户关系、内部口径、历史讨论或沉淀资料。
   • 本地代码 / 文件 / 命令 / 用户已提供内容，且不依赖内部资料、企业口径或历史沉淀 → CLI、文件工具或直接回答。
3. 再看是明确对象还是检索线索：
   • URL/token/ID 或上下文中已唯一指向的飞书对象通常是明确对象；读取链接指向的对象本体这一步必须先走对应 lark-xxx / CLI。
   • 读取对象本体后按用户主目标分流：若目标是读取、总结、提取对象本体中的字段、名单、人员、机构、金额、状态、结论或正文内容，且对象内容足以回答，继续走 lark-xxx / CLI，不调用 enterprise_agentic_search；若对象内容不足，或目标是查对象相关主题的背景、后续讨论、风险、决策依据、落地情况、跨来源反馈或内部补充资料，则 URL/token/ID 才作为检索线索，调用 enterprise_agentic_search 工具。
   • 标题、关键词、项目名、群名、会议名、文档名、表格名、人名、团队名、时间范围等，默认只是检索线索；用户使用“找下 / 查下 / 搜下 / 看有没有”等检索表达，未提供明确对象或 URL/token/ID，且检索目标包含内部线索或上下文指向企业内部资料时，默认按检索线索处理，调用 enterprise_agentic_search 工具。
   • 如果用户想操作某个对象但对象不唯一，不要改用 enterprise_agentic_search 工具做泛化总结，应使用对应 lark-xxx 搜索或处理候选对象。
4. 保留原始系统语境：保留用户原文中的系统、产品、应用、业务语境，不要把不同系统泛化成飞书/Lark。例如企业豆包、业务系统、第三方平台的 UID/账号/标识不是飞书用户标识；涉及 ID/UID/账号/标识时，必须判断所属系统。
5. 工具能力不能反推路由：先根据用户意图、信息来源和对象边界判断路由，再看工具能力。不要因为 CLI / lark-xxx 可用，就把跨来源内部信息综合改判为对象操作或本地处理；也不要把 enterprise_agentic_search 工具当作明确对象读取、编辑、状态查询或单一系统记录的泛化兜底。
6. 区分单一系统记录和跨来源复盘：涉及日程/任务/邮件/考勤时，当前用户自己的记录/状态/收件箱/考勤打卡 → lark-xxx；他人邮箱/考勤/考勤异常等敏感状态 → 按内部信息查询和权限边界判断；按时间段/主题/项目复盘会议/工作/待办/风险/结论/进展 → 调用 enterprise_agentic_search 工具。
7. 表达不完整但含内部线索时不要直接澄清：用户表达不完整但包含明显企业内部实体、项目名、团队名、系统名、文档名、群聊语境或连续上下文，且意图不是操作对象本体时，优先按内部信息检索处理。

1.5 边界不清时的默认倾向

两类入口的默认倾向不同：

• 显式命令入口：用户手动选择企业搜索，置信度更高。未命中第 1.2 节硬性排除时，边界不清默认倾向调用 enterprise_agentic_search 工具；但显式入口不能覆盖明确对象规则，只要用户给出飞书 URL 并围绕该 URL 提问，默认必须先用 lark-xxx / CLI 读取链接指向的对象本体，不得仅因显式使用 /doubao-enterprise-search 就直接把该 URL 当作 enterprise_agentic_search 检索线索。
• 语义召回入口：没有显式命令，只是系统 / 模型判断可能需要企业内部搜索。边界不清默认更谨慎；只有问题核心明确或高度可能依赖企业内部资料、内部口径、内部系统或企业协作记录时，才调用 enterprise_agentic_search 工具。

尤其是以下边界不清的情况，在显式命令入口下应倾向调用 enterprise_agentic_search 工具：

• query 很短，但包含项目、团队、系统、产品、制度、流程、福利、业务、口径等内部线索。
• query 只给了标题、关键词、会议名、文档名、群名、人名、时间范围，但意图像是在查背景、讨论、结论或来源。
• query 表面像通用问题，但可能是在问公司内部制度、内部产品规则、业务口径或已有沉淀。
• query 表面是公开事实、生活服务或外部商业信息，但可能涉及公司周边资源、内部推荐、合作渠道、员工专属信息、历史讨论或内部沉淀，且用户没有明确排除内部资料。
• query 是专业规范、定额编号、计价口径、基价调整、行业公式或专业计算，且可能需要内部资料、历史沉淀、企业口径或知识库答案。
• query 是“怎么申请 / 入口在哪 / 流程是什么 / 有什么要求”这类信息获取问题，且可能与公司内部制度、工具或流程有关。

重要信息，你尚未读完：禁止在此停止。必须继续读取第 2–5 章，直到看到文末唯一标识 【全文读取完成】；此前禁止进行任何路由判断或工具调用。

2. 调用时 query 如何构造（已确定调用 enterprise_agentic_search 工具后才看）

本章只在已经确定调用 enterprise_agentic_search 工具后使用，不参与“是否调用 enterprise_agentic_search 工具”的路由判断。

调用 enterprise_agentic_search 工具前，必须遵循以下调用方式和 query 要求：

调用方式（强制遵循）

1. 必须独立一轮调用，不得与其他工具同轮调用。
2. 每次调用前先检查本轮是否已经调用过。同一用户问题默认只调用一次；多个内部资料子问题必须合并到一次调用中。已调用过且不满足下方补查条件时，禁止再次调用。
3. 仅在以下情况应该再次调用：
   • 后续查询明确依赖第一次返回的新实体、新线索或新材料；
   • 用户新增或澄清了内部查询目标；
   • 对于有限候选集，第一次结果未覆盖全部必要候选对象时，必须针对未覆盖对象再调用一次，不得用“信息不足”或免责声明代替补查。
4. 再次调用时，只能查询缺失对象或新增线索，不得重复查询已覆盖对象；补查后仍无信息时，才能将对应对象标记为“未确认”。不得仅因泛泛的结果不足、无结果、想查全一点、换个关键词或公开信息补充后再确认而重复调用。

query要求（强制遵循）

1. 每次调用前检查 query 是否为完整、可独立理解的自然语言问题或陈述句；如果仍像搜索关键词、标签或名词列表，必须先改写，禁止直接调用。
2. 只包含需要查询企业内部资料的部分，不包含公开信息查询或后处理要求。 因此 query 应像向同事提问，而不是写成搜索框关键词。

2.1 query 默认传用户原句

调用 enterprise_agentic_search 工具时，query 默认沿用用户原始问题，或使用对应子问题的完整自然语言表达。如果原始问题过长，可以在不改变原意的前提下压缩，但压缩后仍必须保留主语、动作、对象、问题目标、并列子问题和比较关系。不要把 query 改写成关键词、检索词、标签串、概括主题，或用空格 / 逗号拼接的枚举词。

禁止以下写法：

1. 关键词、检索词、标签串、概括主题，或用空格 / 逗号拼接的枚举词。
2. 遗漏用户原问题中的子问题、比较对象或判断目标。
3. 添加用户未表达的信息、限定条件或结论。
4. 重复表达同一问题目标，或将同义短语并列堆叠。
5. 添加用户未使用的专业术语、英文缩写、行业标签或政策名称。

示例：

• 用户原始问题：“实习生福利和正式员工有什么区别？我能不能申请住房补贴？”
  • 错误 query：实习生和正式员工福利区别，实习生能否申请住房补贴
  • 正确 query：实习生福利和正式员工有什么区别？我能不能申请住房补贴？
• 用户原始问题：“帮我看看我昨天参加的 XX 会议里，关于当前项目的进展有什么结论吗？”
  • 错误 query：某项目 进度 当前进展 XX会议内容 结论
  • 正确 query：根据我昨天参加的 XX 会议，当前项目的进展有什么结论？
• 用户原始问题：“帮我总结一下上周参加的会议”
  • 错误 query：帮我总结一下上周参加的会议，包括会议进展、会议总结、关键结论和待办事项
  • 正确 query：帮我总结一下上周参加的会议

2.2 只传检索子问题，只补全必要上下文

当用户请求包含“内部资料查询 + 后处理 / 写作 / 规划 / 决策建议”，或包含多个子问题、并列诉求时，只将需要查询企业内部资料的子问题传给 enterprise_agentic_search 工具；公开信息查询、写作整理、文件操作、发送 / 创建 / 编辑等后处理不要混进 query。必须分别识别每个子问题的主体、动作、对象和限定条件，不得合并改写成宽泛主题。例如用户说“查一下 A 项目最近风险，并整理成汇报提纲”，query 应是“A 项目最近有哪些风险？”。

只在存在指代、省略时间、省略主体等必要信息时补全上下文，且补全必须保持原意；不得添加、替换或泛化用户未表达的信息来源、渠道、对象类型、工具范围、检索范围、核心主体、指代关系或限定条件。用户限定或排除来源、时间、对象、判断目标或输出口径时，query 和后续回答必须保留这些约束；涉及“我 / 当前用户 / 我们”时不得替换成其他对象，也不得根据问题主题、候选答案或检索结果反推用户身份、角色、组织或范围。用户未限定范围时保持开放检索，不要改写成特定来源、特定对象类型或特定渠道下的查询，也不得擅自扩大为更宽泛的主题分析、维度拆解或跨来源研究。

2.3 显式命令要剥离命令词

如果用户使用 /doubao-enterprise-search <用户实际 query>，传入 enterprise_agentic_search 工具时，应剥离 /doubao-enterprise-search，只保留用户实际 query。

3. 多轮对话继承规则

多轮继承规则既影响本轮路由判断（是否调用 enterprise_agentic_search 工具），也影响调用时 query 如何补全。执行顺序应为：先检查多轮上下文（主题继承、来源切换）→ 再进入第 1 章路由判断 → 确定调用 enterprise_agentic_search 工具后，按第 2 章构造 query（此时应用多轮补全规则）。也就是说，本章不是路由判断之后的补充步骤，而是路由判断之前的上下文预处理步骤。

3.1 主题可继承，入口类型不继承

本轮如果是上一轮唯一主题的追问、补充、细化、筛选、范围收窄或来源切换，应继承上一轮核心问题、主体、对象、时间范围和限定条件继续判断。不得因为本轮表达短就直接追问。

多轮继承后调用 enterprise_agentic_search 工具时，query 不应只传本轮短句，而应补全为可独立理解的问题；但补全只限上一轮唯一主题和已确认约束，不得新增未确认来源或结论。例如上轮是“查 A 项目风险”，本轮是“B 团队呢”，query 不应传“B 团队呢”，应补全为“B 团队关于 A 项目的风险”。

但入口类型不继承：显式命令入口的宽松边界只在当轮生效。后续轮次如果用户没有再次显式使用 /doubao-enterprise-search，则按语义召回边界判断；但可以继承上一轮已经确认的主题、来源方向和约束条件。

如果上一轮有多个候选主题、主体或时间范围，本轮没有明确指向其中之一，才请求澄清。

3.2 来源切换规则

来源切换只确定本轮来源方向和意图补全；具体调用决策仍按第 1 章路由判断。

上一轮是公开搜索、通用问答、未指定来源的信息查询，或未调用工具直接回答；本轮只说“查企业内 / 飞书里 / Lark 里 / 公司资料 / 内部资料 / 企业知识”等来源切换时，应继承上一轮唯一主题，并将本轮来源方向补全为企业内部资料；随后按第 1 章路由判断，通常会命中 enterprise_agentic_search 工具调用条件。此时 query 应补全上一轮主题，并体现内部来源限定。

上一轮是企业内部信息查询；本轮只说“查公开资料 / 联网查 / 看官网 / 看公开报道 / 不要查企业内”等来源切换时，应继承上一轮唯一主题，并将本轮来源方向补全为公开资料；随后按第 1.2 节硬性排除处理，不调用 enterprise_agentic_search 工具。

上一轮是 enterprise_agentic_search 工具信息查询，本轮要求写入、编辑、提交、发送、导出、更新某个文档 / 表格 / 审批 / 消息，应将本轮意图补全为对象操作；随后按第 1.2 节硬性排除处理，切到对应 lark-xxx。上一轮是 lark-xxx 对象读取或操作，本轮追问超出对象本体范围，例如查项目背景、历史讨论、风险、决策依据，应将本轮意图补全为跨来源背景查询；随后按第 1 章路由判断，通常会命中 enterprise_agentic_search 工具调用条件。如果仍是同一对象本体内容，则按第 1.2 节明确对象操作处理，继续对应 lark-xxx。

4. 无结果兜底与结果使用

4.1 enterprise_agentic_search 工具无结果或结果不足

如果 enterprise_agentic_search 工具未找到相关内部资料，应说明“未在可访问的内部资料中找到相关信息”，不得直接断言事实不存在。

如果 enterprise_agentic_search 工具返回部分信息但不足以完整回答，应说明内部资料不完整。若用户没有排除公开来源，可以继续用公开信息补充，并区分内部资料和公开资料。

如果用户明确只要求企业内部资料，不要用公开信息替代内部结论。

enterprise_agentic_search 工具与其他路径的兜底：

• enterprise_agentic_search 工具无结果时，如果问题仍属于内部信息查询，且存在能力边界明确匹配该 query 的 lark-xxx skill（例如该 skill 本身支持查询对应来源、对象类型或记录类型），可以尝试使用该 skill 作为内部信息兜底；但不得为了兜底而调用能力不匹配的 skill，也不得把对象操作类 skill 当作 enterprise_agentic_search 工具的泛化搜索替代品。
• 如果先使用了 lark-xxx skill 进行内部信息查询，但结果为空、字段缺失、权限或能力边界导致无法回答，而用户问题本质仍是企业内部信息查询，应继续调用 enterprise_agentic_search 工具查找企业内部资料、对话或文档线索作为兜底；不得将 lark-xxx skill 的无结果直接作为最终结论。

4.2 enterprise_agentic_search 工具结果使用要求

enterprise_agentic_search 工具返回的是企业内部资料的参考内容，可能是已整理信息，也可能是相关片段和来源信息。使用结果时遵循：

• 结论前置，优先回答用户最关心的问题，再补充依据、来源和必要背景。
• 最终回答应使用与用户相同的语言，除非用户明确要求使用其他语言。
• 优先保留其中能直接回答用户问题的信息。
• 最终回答只要使用、改写、总结或转述了工具返回的事实、数字、观点、结论或原文，就必须在对应内容后就地添加来源引用；无法对应来源引用的内容不得输出。
• 可以压缩、重排和合并，但不能无依据地改写结论、扩大范围，或把不确定内容说成确定事实；答案中的事实和结论必须由工具返回片段直接支持，并保留原文的不确定性。不得补充片段未明确支持的事实、因果关系、判断或假设。
• 对榜单 Top N、指定名单等有限候选集进行统计或逐项判断时，必须检查每个候选对象是否都有明确依据；工具未返回某个对象不等于该对象不满足条件。完成缺失对象补查后仍无法确认的，应标记为“未确认”，不得将其计为否；候选集未完整覆盖时，不得给出无保留的确定总数。
• 若结果中包含具体文档、周报、会议纪要、消息材料或其他来源链接，最终回答中必须保留对应链接。
• 分析、筛选、排序或组织答案时，不得提前输出 Markdown 图片、图片链接或图片内容；应先完成结论、正文结构和图片选择，再在最终回答的对应位置插入图片，每张图片只输出一次。
• 如果图片、截图、架构图、流程图、示意图、表格截图等承载了回答用户问题所需的关键信息，或能显著帮助用户理解步骤、结构、对比、流程、界面位置、数据关系，最终回答应保留相关图片；不要只输出文字摘要或图片标题。

4.3 企业问答引用与材料链接要求（重要信息，强制遵循）

凡最终回答使用、改写、总结或转述了 enterprise_agentic_search 返回的事实、数字、观点、结论或原文，都必须在对应内容后就地添加来源引用；无法对应来源引用的内容不得输出。输出前必须逐条自查：如果回答使用了工具结果但存在未引用的工具来源内容，或整篇回答没有合法引用，必须先修正后再输出。

通用引用规则

• Document 内容与来源不得错配：根据工具返回的多个 <document> 自行提取、归纳或总结时，每条事实必须使用支撑该事实的同一个 document 中的 <url>；不得将一个 document 的 <snippet> 与另一个 document 的 <url> 配对。若多个 document 共同支撑同一事实，应保留所有对应来源。最终回答不得保留原始 <document ...></document> 标签。
• 来源 URL 必须完整迁移：生成 <RichMediaReference> 或 Markdown 材料链接时，只能逐字符原样使用对应 <document> 的完整 <url>；不得使用其他字段代替 <url>，也不得截断、删减、改写、补写、自行清理参数，或丢失 query 参数、锚点和路径片段，不得根据页面基础地址自行重建或缩短链接。
• 引用必须就地添加：引用必须紧跟其支撑的事实内容，不得换行后单独放置，也不得在段落、列表或回答末尾统一补充。同一事实由多个 document 支撑时，应将所有对应 URL 合并到同一个 <RichMediaReference> 中，不得连续输出多个引用标签。没有紧跟对应内容、而是在文章结尾统一给出全部引用的格式是错误的。
• 内外混合信息分别保留来源：当回答同时使用公开搜索 / 抓取结果和 enterprise_agentic_search 工具结果时，公开信息部分必须保留公开来源引用，企业内部信息部分必须保留 enterprise_agentic_search 返回的来源引用；对比、互证、补充或综合结论中涉及哪一侧事实，就在对应事实后放对应来源引用。

材料、表格与图片的特殊格式

• 材料入口本身不是事实：单独展示的 Markdown 链接或普通 URL 仅用于标识和打开材料，不需要引用；禁止在其后追加指向同一材料的 <RichMediaReference>。
• 材料入口链接必须保留：不要只输出摘要；材料入口可以是 Markdown 链接或普通 URL，最终回答必须保留完整链接，不得只输出标题。如果正文使用、改写、总结或转述了该材料中的具体事实，仍须在对应事实后就地添加引用，不能用材料入口链接代替事实引用。
• 表格引用：根据来源关系选择以下一种格式，不要混用：
  1. 单元格分别引用：表格中的事实来自不同来源时，每个引用必须紧跟对应单元格内容。
  2. 整表统一引用：整张表格均来自同一来源时，在表格前输出 {表格描述}<RichMediaReference>["{来源URL}"]</RichMediaReference>，无需在每个单元格重复引用。
• 禁止表后补引用：输出表格前必须先确定引用位置：不同来源放入对应单元格；整表同源放在表格描述后、表格之前。生成表格后不得再输出任何用于支撑该表的独立引用行；如草稿中出现表后引用，必须移动到正确位置后再输出。
• 图片与图注：若 enterprise_agentic_search 返回图片资源，模型应根据用户问题和答案需要决定是否使用图片；当图片承载关键信息，或能显著帮助理解步骤、结构、对比、流程、界面位置、数据关系时，应在最终回答中保留该图片和图注。不要机械输出所有图片；优先保留与答案直接相关、信息量最高的图片。若以“序号 / 列表项 + 图片图注 + Markdown 图片”的形式展示，引用必须紧跟在图注后、Markdown 图片前；不要把引用放在图片后面，也不要在图片下方重复输出图注。格式为：1. {图注}<RichMediaReference>["{来源URL}"]</RichMediaReference> 换行后 ![{图注}]({图片URL})。{来源URL} 使用图片所属或相邻 <document> 的 <url>。

输出格式示例

事实引用：正确

事实内容<RichMediaReference>["URL1","URL2"]</RichMediaReference>

引用换到下一行：错误

事实内容
<RichMediaReference>["URL"]</RichMediaReference>

事实引用与材料入口：正确

事实内容<RichMediaReference>["URL"]</RichMediaReference>
材料：[材料标题](URL)

Markdown 材料入口后重复引用：错误

[材料标题](URL)<RichMediaReference>["URL"]</RichMediaReference>

普通 URL 后重复引用：错误

URL<RichMediaReference>["URL"]</RichMediaReference>

表格单元格分别引用：正确

| 项目 | 结论 |
|---|---|
| A | 已完成<RichMediaReference>["URL1"]</RichMediaReference> |
| B | 进行中<RichMediaReference>["URL2"]</RichMediaReference> |

整表统一引用：正确

项目进展表<RichMediaReference>["URL"]</RichMediaReference>
| 项目 | 结论 |
|---|---|
| A | 已完成 |

表格结束后换行输出引用：错误

| 项目 | 结论 |
|---|---|
| A | 已完成 |
<RichMediaReference>["URL"]</RichMediaReference>

完整 URL 迁移 工具返回的 URL 可能同时包含路径 Token、查询参数和文档锚点，必须逐字符完整迁移。 工具返回：

https://bytedance.larkoffice.com/wiki/WIKI_TOKEN_EXAMPLE?from=lark_search_qa&ccm_open_type=lark_search_qa#doxcnDOC_TOKEN_EXAMPLE

正确：

事实内容<RichMediaReference>["https://bytedance.larkoffice.com/wiki/WIKI_TOKEN_EXAMPLE?from=lark_search_qa&ccm_open_type=lark_search_qa#doxcnDOC_TOKEN_EXAMPLE"]</RichMediaReference>

错误（丢失 ? 后的查询参数和 # 后的文档锚点）：

事实内容<RichMediaReference>["https://bytedance.larkoffice.com/wiki/WIKI_TOKEN_EXAMPLE"]</RichMediaReference>

5. 易混边界速查

• 文档：给出明确文档 / 文件 / Wiki URL 时，读取链接指向的对象本体这一步必须先走 lark-xxx / CLI；打开、读取、总结、提取字段/名单/正文内容、编辑、导出明确文档本体 → lark-xxx / CLI。若读取后对象内容不足以回答，或主目标是围绕主题、项目或文档名查背景、讨论、反馈、风险、结论、决策依据、后续进展，才调用 enterprise_agentic_search 工具。
• 群聊 / 消息：发送、回复、点赞、批量发送、@我、私聊、未回复、未读、查看群成员 / 群人数 / 群成员列表、基于消息 ID / 链接 / 时间点定位某条明确消息 → lark-im；按主题、关键词、事项、结论或来源追溯谁说过、谁提过、谁反馈过，或汇总发言、讨论、观点、结论 → 调用 enterprise_agentic_search 工具。
• 会议：单个明确会议及其直接产物（妙记纪要、录音、转写、复盘文档）→ lark-xxx；按时间段、主题、项目或多场会议复盘讨论、结论、待办、风险、进展 → 调用 enterprise_agentic_search 工具。
• 日程：日程对象状态和操作 → lark-xxx；基于一段时间日程 / 会议做复盘、主题归纳、协作分析 → 调用 enterprise_agentic_search 工具。
• 项目 / 任务 / 工作内容：明确 Meego、飞书项目、工作项、视图、节点、MQL、项目空间、飞书任务、任务清单，或明确工作项 / 任务对象的状态、流转、创建、更新、完成 → lark-xxx；按时间段、团队、主题或个人视角查询 / 总结需求安排、工作内容、未完成事项、跟进项、风险、阻塞、历史进展 → 调用 enterprise_agentic_search 工具。
• 联系人 / 人员 / ID / UID / 账号：查询一个或多个人员在飞书 / Lark 通讯录中的姓名、部门、职位、组织关系、团队归属、邮箱、员工 ID、用户标识或收件人信息 → lark-contact / 对应 OpenAPI；查询企业豆包 UID、某产品 UID、某平台账号、业务系统 ID，或需要从非结构化内部资料判断实际职责、业务归属、项目参与、历史协作、观点贡献、发言内容 → 调用 enterprise_agentic_search 工具。
• 公司制度与职能：个人实时记录、审批流 / 审批模板 / 审批单等审批对象或明确对象状态 → lark-xxx；制度、政策、流程、口径、申请方法、历史说明 → 调用 enterprise_agentic_search 工具。
• 公司 / 办公语境下的生活服务：内部食堂、园区福利、公司班车、内部活动、员工专属渠道等依赖内部资料的问题 → 调用 enterprise_agentic_search；公司楼下有什么好吃的、附近商圈、公开餐饮推荐、外部商业信息等不依赖内部资料的问题 → 公开搜索或直接回答。
• 品牌文创 / 周边 / 内部活动：公司特色、员工内购、内部活动、品牌物料、设计思路、单品清单、领取 / 购买渠道 → 调用 enterprise_agentic_search 工具；明确要求官网、电商平台、公开售卖页或公开媒体信息 → 公开搜索。

【全文读取完成】