TaskLens 项目面试问答卷

State 保存一次任务执行过程中共享的业务数据，包括原文、Requirement、检索结果、ActionTask 和审批状态。Node 是执行单一职责的处理单元，只返回自己负责更新的 Partial State，减少耦合、防止误覆盖。Edge 定义节点之间的固定流转路径，Conditional Edge 则根据 State 选择不同分支，使检索循环、异常处理和人工审批等场景得以显式表达。Checkpoint 负责持久化各阶段的 State，使工作流能够在服务重启或人工审核后从中断位置继续执行，thread_id 用于标识并隔离不同工作流实例。

文档解析：将企业通知、制度 PDF 和项目申报材料解析为保留章节边界的结构化中间表示。证据抽取：提取关联到具体原文证据的 Requirement 对象，精确到句子、条款和数字，附带来源坐标信息。后备检索：当直接证据不足时，通过定向 RAG 检索进行补充，后备路径会被标记，下游消费者可查看其来源。

系统首先解析文档并抽取带原文证据的 Requirement。当证据不足时才触发 RAG 检索。检索阶段通过 BM25 和 Dense 分别完成词法召回与语义召回，再使用 RRF 融合多个检索通道和多个 Query 的排名，并对补充通知进行版本冲突合并。最终系统生成 Requirement、Evidence、Change 和 ActionTask 结构化对象。

TaskLens 与普通摘要系统最大的区别，是每个 ActionTask 都可以反向追溯到具体文件、Chunk 和原文依据，并在执行前进入人工审批。不是返回一段无法验证的摘要，而是给出可审计、可执行的结构化任务。

Evidence Gate 需要检查 Requirement 中的动作、对象、材料、时间和责任人等字段是否都有原文依据，同时验证证据来源是否可追溯、证据与结论是否一致，以及是否存在新旧版本冲突。

证据不足时，不应马上转人工。先生成或改写 Query，通过 BM25 和 Dense 补充检索，再经过 RRF 融合和 Parent 上下文回填后重新验证。只有达到最大检索次数、仍然缺少证据或存在无法自动处理的冲突时，才转人工。

设置最大次数是为了防止 Agent 在原文根本不存在相关信息的情况下无限循环，造成 Token、时间和计算资源浪费。达到上限仍未找到足够证据时，系统将任务标记为人工处理。

Evidence Gate 会逐字段检查原文依据，缺失关键字段时围绕项目名称、申请书、公章等实体和同义表达生成 Query，通过 BM25 和 Dense 进行补充检索，扩大覆盖范围。达到最大检索次数仍找不到可靠证据时，将该字段标记为无证据支持，不生成确定性任务，并提交人工处理。

系统不能只根据发布时间判断文件是否有效，而要综合来源权威性、文件类型、适用范围、版本关系、生效时间以及是否包含延长、取消、以本通知为准等明确变更措辞。

文件 B 属于正式补充通知，并明确将文件 A 的截止时间延长至 8 月 20 日，因此截止时间应采用文件 B。文件 C 只是网页转载，与正式文件冲突时不能覆盖官方通知。不能单纯选择发布时间最新的文件，因为来源权威性比发布时间更重要。

added 表示新增要求。updated 表示原有要求的字段被修改。removed 表示原有要求被明确取消。conflict 表示多个来源存在矛盾且无法确定覆盖关系，此时系统会将冲突标记出来，等待人工处理。

文件 B 中的其他事项不变表示进行字段级增量合并：只更新截止时间，其他字段继续继承文件 A，并分别保留各字段的证据来源。这样既保证了数据完整性，又保留了每个字段的独立可追溯性。

当部分字段有证据支持、部分字段被另一份证据明确否定时，应判断为 unsupported 或 contradicted，而不是 partial。系统直接修正 Requirement 并记录一条 removed 类型的 Change，而不是继续改写 Query 检索。

idempotency_key 用于防止网络重试导致重复执行。同一个键重复请求时，系统只执行第一次，后续直接返回第一次的执行结果。如果键相同但内容不同，则应拒绝该请求。

审批接口仅允许 pending 到 approved 一次，并发或连续点击只生效一次。后续重复点击直接返回原审批结果，不触发重新执行。

外部侧效应透传 idempotency_key 确保下游 API（日历、邮件、消息）也只触发一次，防止重复创建日历事件或重复发送消息。

approve_id 用于唯一标识一次审批请求并绑定审批状态。content_hash 用于记录用户批准内容的数字指纹。执行前系统会重新计算当前任务的哈希，只有与审批时的哈希一致才允许继续执行。

任务内容在审批后被修改时，原审批必须失效并重新确认。content_hash 会在执行前重新校验，如果发现当前内容哈希与审批时的哈希不一致，系统会拒绝执行并要求重新提交审批。

用户批准的是包含申请书.pdf 在内的显式契约。替换为最终申请书.pdf 属于 payload 变更，原审批必须失效并重新确认。approve_id 状态保留并标记为 expired / invalidated 作为审计快照。当前内容重新计算的 content_hash 与审批快照中的哈希不一致，系统直接拦截执行。

即使字节内容完全一致，文件名变更同样破坏了用户可见契约，必须重新验证。这防止了侧信道注入与契约漂移：用户批准的不是字节，而是他们看到的完整 payload 表示。

BM25 词法匹配，精确查找术语和条款；Dense 向量检索，跨通知进行语义相似度匹配。每个通道独立运行，附带置信度评分。

对多通道输出执行 Reciprocal Rank Fusion (RRF)，多 Query 扩展覆盖不同表述方式，最终排名列表附带每项结果的来源元数据。

检测跨文档版本的交叉或矛盾条款。优先级逻辑：补充通知覆盖原通知、较晚日期默认优先。所有冲突决策记录在审计追踪中，供后续审查。

系统使用 Child Chunk 进行精确检索（BM25 词法匹配 + Dense 语义匹配），命中后再自动回填它所属的 Parent 章节，从而兼顾定位精度和上下文完整性。

pytest 显示 100% 通过，只能说明当前编写的测试用例全部符合预期，不能证明系统不存在问题，也不能把测试通过率当作模型准确率。

测试集可能覆盖不足，断言可能不严格，单元测试也可能使用 Mock。真实环境还存在 LLM 输出波动、复杂文档、知识库噪声和外部服务异常等不可控因素。

RAG 需要评估 Recall@K、Precision@K、Hit@K、MRR（平均倒数排名）、证据覆盖率和检索延迟，全面衡量检索结果的质量和效率。

ActionTask 需要检查动作、材料、截止时间等字段的准确率以及是否存在无证据任务。冲突处理要分别构造 added、updated、removed 和 conflict 案例。中断恢复要模拟服务重启，验证相同 thread_id 能从 Checkpoint 继续，同时测试审批哈希失效和幂等执行。

将业务场景建模为可组合的 Agent 工作流。每个场景定义自己的通知来源、抽取规则、审批链和派发目标。可在保留溯源核心的基础上扩展自定义字段。

策略以结构化 Schema 定义，通过 Pydantic 在运行时校验：检查必填字段、数据类型、枚举值、数值范围以及自定义业务规则。校验失败时抛出明确错误，由工作流决定重试、停止或转人工处理。

门控可按照通知类型、优先级或风险等级灵活配置。审批人可查看完整证据链：来源文件、条款、提取文本、拟派发的 ActionTask。审批驳回和修改本身也作为审计事件记录。

不能直接把长文档全部交给大模型。首先可能超过上下文窗口。即使没有超过，也会增加 Token 成本和响应延迟，并且大量无关内容会稀释关键要求，造成字段遗漏和证据定位困难。

TaskLens 先按照标题、条款、段落和表格进行结构感知切片。如果某个章节仍然过长，再按照句子和长度进行递归切分，并保留一定 Overlap 确保上下文不中断。

系统使用 Child Chunk 进行精确检索（BM25 词法匹配 + Dense 语义匹配），命中后再自动回填它所属的 Parent 章节，从而兼顾定位精度和上下文完整性。

Chunk 太大会增加噪声、降低检索区分度。Chunk 太小则可能把标题、主语和要求拆开，造成语义不完整。因此 Chunk 大小和 Overlap 需要在验证集上结合 Recall、准确率和 Token 成本进行调整。

State 保存一次任务执行过程中共享的业务数据，包括原文、Requirement、检索结果、ActionTask 和审批状态。每个 Node 都可以读取和更新 State，确保整个工作流的数据一致性。

Node 是执行单一职责的处理单元，例如文件解析、证据判断和检索。每个 Node 只返回自己负责更新的 Partial State，减少耦合、防止误覆盖，方便状态合并和单元测试。

Edge 定义节点之间的固定流转路径。Conditional Edge 则根据 State 选择不同分支，使检索循环、异常处理和人工审批等场景得以显式表达。

Checkpoint 负责持久化各阶段的 State，使工作流能够在服务重启或人工审核后从中断位置继续执行。这是普通函数调用链难以实现的。

系统保存文件的版本关系与变更历史。Change 对象完整记录了变更原因和版本关联，确保审计时能够回溯整个变更历史。旧 Requirement 被标记为失效或被替代，新 Requirement 成为当前生效版本。

Checkpoint 需要持久化文档解析结果、Requirement、Evidence、检索结果、ActionTask、当前执行阶段、重试次数、错误信息以及 approve_id、审批快照、content_hash 和幂等执行状态。这样才能在任意节点恢复执行。

thread_id 用于标识并隔离不同工作流实例，即使状态保存在同一个 SQLite 数据库中也不会相互串线。恢复时使用原来的 thread_id，Checkpointer 才能找到对应的状态历史和暂停位置。

不能生成 ActionTask 后直接执行，因为写入日历和发送提醒属于有副作用的外部操作，任务内容可能存在抽取错误，所以需要人工审批。审批通过后才能执行外部操作。

外部侧效应透传 idempotency_key 确保下游 API（日历、邮件、消息）也只触发一次，防止重复创建日历事件或重复发送消息。

系统应先通过任务元数据中的 idempotency_key 或关联属性反查日历平台 API，客观确认外部状态，不依赖本地假设。若确认已创建成功，将本地幂等记录补全 external_result_id 并更新 status 为 success；若确认未创建，透传原 idempotency_key 安全重试，确保下游 API 仍只触发一次。

Node 是执行单一职责的处理单元，例如文件解析、证据判断和检索。每个 Node 只返回自己负责更新的 Partial State，减少耦合、防止误覆盖，方便状态合并和单元测试。

将业务场景建模为可组合的 Agent 工作流。每个场景定义自己的通知来源、抽取规则、审批链和派发目标。可在保留溯源核心的基础上扩展自定义字段。

固定的线性流程可以用普通函数完成，但 TaskLens 存在证据不足时的检索循环、异常分支、人工中断、恢复执行和状态历史。LangGraph 让流程更显式、更容易测试和恢复。

主要瓶颈在 LLM 推理延迟、文档解析与向量检索。整篇输入会激增 Token 成本和响应延迟，因此通过结构感知切片控制单次请求规模，通过 BM25 与 Dense 双路检索控制检索延迟。

审批接口仅允许 pending 到 approved 一次，并发或连续点击只生效一次。外部侧效应透传 idempotency_key 确保下游 API 也只触发一次，防止并发下重复创建或重复发送。

通过缓存（解析结果、向量索引、Checkpoint）降低重复计算，通过横向扩展处理更多并发请求，并受外部服务限流约束。QPS 需要结合 LLM 推理延迟和外部 API 限流综合评估。

无服务器环境下首次调用需要加载运行时与依赖，带来额外延迟。对 LLM 工作流而言，冷启动叠加推理延迟会明显拉长首次响应时间。

缓存文档解析结果与向量索引，避免重复切片与向量化；通过 Checkpoint 持久化中间状态，避免中断后从头重跑；对已入库文档复用其 Evidence 与 Requirement，减少重复抽取。

已解析文档的 Evidence 与 Requirement 被持久化，后续相同文档无需重新抽取。中断任务从 Checkpoint 继续而非从头执行，既降低延迟又避免结果漂移。

只在前端保存审批页面是不够的，因为浏览器刷新、关闭或服务重启后，前端无法恢复完整的业务 State，而且前端提交的审批状态不能作为可信的唯一来源。审批状态和业务数据必须在服务端持久化。

Checkpoint 需要持久化文档解析结果、Requirement、Evidence、检索结果、ActionTask、当前执行阶段、重试次数、错误信息以及 approve_id、审批快照、content_hash 和幂等执行状态。这样才能在任意节点恢复执行。

thread_id 是一次工作流实例的唯一标识。恢复时使用原来的 thread_id，Checkpointer 才能找到对应的状态历史和暂停位置。如果换了 thread_id，系统无法关联到之前的审批状态和执行进度。

需比对文件内容哈希和版本。若变化影响当前 Requirement，将原任务标记为 expired / invalidated，原审批失效，生成新任务重新审批，已审批的任务不能被静默替换。审批接口保持幂等。邮件状态为 executing 且无外部 ID 时不能直接重发，必须先反查外部平台确认真实状态。审计日志追加保留完整事件链，不得覆盖历史记录。

QPS 即 Queries Per Second，指系统每秒能处理的查询或请求数量，用于衡量系统的吞吐能力。与之相关的还有 TPS（每秒事务数）、RT（响应时间）等指标，共同描述系统的性能特征。

QPS 等于总请求数除以时间窗口（秒）。通常通过压测工具在特定并发下测量，并记录对应的响应时间（RT）与错误率，综合评估系统在峰值负载下的表现。

在并发有限时，QPS 与响应时间（RT）相关：系统能支撑的 QPS 大致等于并发数除以平均响应时间。降低 RT 或提升并发都能提高 QPS。

Grounding 指将大模型的输出锚定到真实、可验证的上下文或数据源上，使模型的回答有据可依。缺乏 Grounding 时，模型可能产生幻觉，即生成看似合理但无事实依据的内容。

TaskLens 通过 Evidence Gate 逐字段验证原文依据，确保每个字段都有原文支撑。证据不足时触发补充检索，只有达到最大检索次数仍缺少证据时才转人工，从机制上保证输出可追溯、可验证。

在企业通知与合规场景中，截止时间、材料要求等字段一旦出错会造成严重后果。Grounding 确保每个结论都能追溯到原文，支持审计与责任认定，是企业级智能体的核心能力。

TaskLens 采用分层架构：文档解析与切片、证据抽取、Evidence Gate 校验、后备 RAG 检索、版本冲突解决、人工审批门控、幂等执行与不可变审计日志。每一层都有明确的输入输出与追溯关系。

系统优先选择精确、可引用的原文材料，RAG 仅在直接证据不足时作为后备方案使用。通过切片控制 Token 成本，通过最大检索次数防止无限循环浪费资源。

外部操作必须通过审批门控，审批人可查看完整证据链。无法自动解决的冲突标记为 conflict 并将 need_human 设为 true，等待人工裁决，而不是擅自选择。

LLM 的非确定性会导致重新生成的 ActionTask 发生漂移。因此恢复时必须直接从快照载入 payload，不能重新调用 LLM，确保用户批准的内容与实际执行的内容一致。