TaskLens

传统大模型处理企业通知时，容易生成没有原文依据的结论，也经常混淆原通知和补充通知，导致截止时间、材料要求等关键字段判断错误。TaskLens 通过基于原文证据的抽取机制解决了这一问题。

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

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

我主要负责业务场景定义、工作流拆分、Requirement–Evidence–Action 数据模型设计以及严格 Benchmark 重构。

不能直接把 100 页文档全部交给大模型。首先可能超过上下文窗口。即使没有超过，也会增加 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，使工作流能够在服务重启或人工审核后从中断位置继续执行。这是普通函数调用链难以实现的。

固定的线性流程可以用普通函数完成，但 TaskLens 存在证据不足时的检索循环、异常分支、人工中断、恢复执行和状态历史。LangGraph 让流程更显式、更容易测试和恢复。thread_id 用于标识并隔离不同工作流实例，即使状态保存在同一个 SQLite 数据库中也不会相互串线。

JSON 语法正确只是第一步。字段可能为空（evidence 为空字符串）、类型错误（confidence 传了字符串）、置信度越界（超过 100），或者缺少业务必需的证据来源。TaskLens 需要对这些情况做出明确判断。

Pydantic 用于运行时数据解析和校验。可以检查必填字段、数据类型、枚举值、数值范围以及自定义业务规则。校验失败时抛出明确错误，由工作流决定重试、停止或转人工处理。

TypedDict 主要用于描述普通字典的结构，提供静态类型提示，本身通常不进行运行时校验。Pydantic 则会在运行时真正验证数据，检查字段是否存在、类型是否正确、值是否在允许范围内。

Pydantic 不能消除大模型幻觉。结构校验只保证数据格式符合 Schema，不保证内容真实性。因此还必须通过 Evidence Gate、原文匹配和来源追踪来验证内容的准确性。

现有 Evidence 只说明需要及时提交材料，并不能支持"风险评估表"和"8月20日"这两个关键字段。直接生成 ActionTask 等于让大模型凭空补全了原文不存在的细节，这是典型的幻觉。

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

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

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

Requirement 是从通知或制度文件中抽取出的业务要求，例如提交对象、材料、截止时间和约束条件。ActionTask 是根据已经验证的 Requirement 生成的具体执行任务，包括动作、负责人、截止时间和审批状态。Requirement 是静态的业务描述，ActionTask 是动态的执行单元。

不能直接从原文生成 ActionTask，因为原文可能包含描述性内容、旧版本要求或不完整字段，大模型也可能误判和幻觉。所以需要先经过 Evidence 验证、Requirement 结构化和版本冲突处理，确保每个字段都有原文支撑后才能生成 ActionTask。

ActionTask 通过 Requirement ID 关联 Requirement，Requirement 再通过 Evidence ID 追溯到具体文档、Chunk、章节和原文片段。每一层追溯都有明确的 ID 和字段映射，审计时可以逐层展开验证。

应记录一条 updated 类型的 Change，保留旧值（8月15日）和新值（8月20日），将旧 Requirement 标记为失效或被替代，并让新 Requirement 成为当前生效版本。Change 对象完整记录了变更原因和版本关联，确保审计时能够回溯整个变更历史。

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

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

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

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

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

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

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

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

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

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

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

虽然可以从头重新执行，但这会增加成本，还可能因为模型输出或知识库变化导致结果漂移、审批内容失效，甚至重复创建日历或发送消息。因此应该从 Checkpoint 继续，并通过幂等键保护外部操作。

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

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

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

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

该证据不能通过 Evidence Gate，因为它只支持材料需要真实完整，不能支持申请书必须盖章这一结论。证据与结论之间缺少直接的语义关联。

缺失的是盖章要求这一关键字段。现有证据只提到内容真实完整，完全没有涉及公章、签字或盖章等具体要求。

下一轮会围绕项目名称、申请书、公章、签字盖章等实体和同义表达生成 Query，通过 BM25 和 Dense 进行补充检索，扩大覆盖范围。

如果达到最大检索次数仍找不到可靠证据，就将该字段标记为无证据支持，不生成确定性任务，并把检索记录和缺失信息提交人工处理。

责任主体（各申报单位）、8 月 20 日截止时间和电子版上传要求均有证据 A 支撑。这些字段通过了 Evidence Gate 的原文匹配验证。

同时提交纸质版的要求没有得到任何证据支持，反而被证据 B 中的"不再要求提交"明确否定。证据与结论之间存在直接矛盾。

当前 Requirement 整体包含事实冲突，应判断为 unsupported 或 contradicted，而不是 partial。因为部分字段不仅有证据缺失，还存在被另一份证据明确否定的情况。

由于现有证据已经足以确定电子版需要提交、纸质版被取消，系统应直接修正 Requirement 并记录一条 removed 类型的 Change，而不是继续改写 Query 检索。

最终只需要提交电子版材料。文件 B 明确取消了文件 A 中的纸质版提交要求，因此不需要再提交纸质版。

文件 B 明确取消了文件 A 中的纸质版提交要求，因此该字段属于 removed，而不是 updated。B 中的"其他事项不变"表示电子版要求继续继承文件 A。

不能因为文件 C 发布时间最晚就采用它。C 只是新闻稿，权威性和规范效力低于正式补充通知，并且没有明确覆盖 B。来源权威性比发布时间更重要。

最终电子版要求引用文件 A，并由文件 B 中的"其他事项不变"确认其继续有效。纸质版取消则直接引用文件 B 中的取消条款。

系统无法自动确定最终截止时间。B 和 C 都是正式来源，适用范围和发布时间相同，也没有明确的覆盖关系，因此应标记为 conflict。

这是 conflict 而不是 updated。B 和 C 都没有提到对方，也没有说明"以本通知为准"，因此系统无法判断哪一份覆盖另一份，只能标记为无法自动解决的冲突。

系统需要保留两个候选截止时间、对应文件、原文证据、来源部门和冲突状态，并将 need_human 设为 true，等待人工介入。

不能先生成 8 月 20 日的确定性 ActionTask 再让用户审批。这等于在证据不足时擅自选择 B。系统应先让人工解决事实冲突，确定有效截止时间后，再生成任务并进入执行审批。

用户批准的是包含申请书.pdf 在内的显式契约。替换为最终申请书.pdf 属于 payload 变更，原审批必须失效并重新确认。approve_id 状态保留并标记为 expired / invalidated 作为审计快照。

当前内容重新计算的 content_hash 与审批快照中的哈希不一致，系统直接拦截执行，并保持原审批状态为 invalidated 供审计追溯。

系统拒绝自动发送，保留旧审批日志，生成全新的 approve_id 及对应快照，重新请求用户二次确认。用户看到的即将批准的内容必须与最终执行的内容完全一致。

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

必须使用 notice-001。thread_id 是工作流实例的唯一隔离标识，Checkpointer 依赖它锁定中断点的 State 并完成快照反序列化。换了 thread_id 就无法关联到之前的审批状态和执行进度。

校验 approve_id、审批状态（pending）、审批快照及当前 content_hash 的一致性，并确认任务未被重复执行。任何不一致都拒绝放行，防止状态漂移。

LLM 的非确定性（Non-determinism）会导致重新生成的 ActionTask 发生漂移。必须直接从快照载入 payload，不能重新调用 LLM，否则用户批准的内容与实际执行的内容可能不一致。

审批接口仅允许 pending -> approved 一次，并发或连续点击只生效一次。外部侧效应透传 idempotency_key 确保下游 API（日历、邮件、消息）也只触发一次。

无需重新发起审批，但绝不能直接盲目重试 API。原审批快照和 content_hash 仍然有效，问题出在执行侧而非审批侧。盲目重试可能生成重复日历事件。

status 为 executing 表示请求已发出，可能已在第三方服务落盘，仅响应超时丢失。executing 比"完全无记录"更危险，因为系统无法区分"已创建但丢响应"和"尚未创建"。

系统应先通过任务元数据中的 idempotency_key 或关联属性反查日历平台 API，客观确认外部状态。不依赖本地假设，而是向第三方服务求证。

若确认已创建成功，将本地幂等记录补全 external_result_id 并更新 status 为 success。若确认未创建，透传原 idempotency_key 安全重试，确保下游 API 仍只触发一次。

仅记录任务执行成功无法完成因果追溯，无法证明谁在何时批准了何种具体 Payload，也无法审计重试与契约漂移。泛化日志对审计来说基本无用。

一次写操作（如发邮件）必须包含 thread_id、approve_id、content_hash、idempotency_key、收件人/主题/附件元数据、审批快照时间戳、外部 message_id 以及溯源的 Requirement ID 和 Evidence ID。

邮件正文与附件不应明文直接打入日志，应存储 content_hash、摘要及受控存储的引用指针。兼顾隐私安全与不可篡改验证。

执行失败后再成功，必须新增成功日志节点，保留全链路重试与纠错状态机轨迹。日志是历史事实，严禁覆盖或修改，必须采用 Append-Only 模式。

需比对文件内容哈希和版本。若变化影响当前 Requirement，将原任务标记为 expired / invalidated，原审批失效，生成新任务重新审批。已审批的任务不能被静默替换。

审批接口必须保持幂等，只允许状态从 pending 转换为一次 approved。后续重复点击直接返回原审批结果，不触发重新执行。

邮件状态为 executing 且无外部 ID 时不能直接重发，防止重复发送。必须先反查外部平台确认真实状态。

透传 idempotency_key、收件人、主题和 content_hash 查询邮件平台。确认已发送后补录 external_message_id，并将幂等状态修正为 success。

审计日志需追加保留完整事件链：任务生成 -> 审批 -> 执行发起 -> 网络中断 -> 重复审批拦截 -> 外部反查对账 -> 状态修正 -> 知识库版本变更。不得覆盖历史记录。