任务雷达处理的是协作中的一个常见断点：行动项分散在群聊、会议转写和临时 @ 中。系统先筛出高信号片段，再用语义层判断责任人、期限和动作，并保留原文证据。
一周可能有上千条群消息，真正需要执行的行动项不到 1%。系统必须先筛信号。
“这块你来负责”常常只出现在会议转写里。会后若没有整理，责任和期限很快消失。
任务系统不能只说“AI 判断你要做”。每条任务都应指向原消息或原转写。
抓取、过滤、定位和合并交给规则与统计；LLM 只处理少量高信号片段。这样成本更低，解释链更清楚。
以派活人作为锚点，而不是维护固定群列表。新项目群出现后，系统仍能纳入相关信息。
派活人、@ 我、祈使句和截止时间获得更高权重；闲聊默认折叠。
会议链接出现在沟通流后，系统识别、鉴权、拉取转写，并定位点名行。
模型只读取高信号片段，判断是否构成任务，并输出动作、责任人、期限和来源。
同一件事在群聊和会议里重复出现时，系统合并为一条任务，并保留全部来源。
任务通常由具体发言人触发。以派活人反查信息源，比维护群名列表更稳定。
脚本负责抓取和定位；模型负责判断“这句话是否构成任务”。每层只处理适合自己的问题。
每条行动项都携带来源、发言人、原话和时间，方便用户自行核对。
| 全文输入 | 分层转化机制 | |
|---|---|---|
| 输入规模 | 全量文本进入 prompt | 只输入高信号片段 |
| 范围更新 | 手动维护群列表 | 以派活人反查来源 |
| 来源追溯 | 引用可能由模型生成 | 结构化引用逐条回溯 |
| 跨源合并 | 上下文超限时难以对齐 | 显式语义对齐 + 来源合并 |
| 隐私暴露 | 大量原文进入模型 | 只有高信号片段进入模型 |
左侧是合成群聊和会议转写，右侧是聚合结果。点击来源标签，可以回到触发任务的原文。
展示之外，本项目的学术部分是一套真实数据评估协议。论文将报告行动项抽取、来源归因和成本对比。
| 设置 | 检验问题 | 状态 |
|---|---|---|
| − 会议转写源 | 口头派活对召回率的贡献 | 进行中 |
| − 发言人加权 | 加权策略对精确率的贡献 | 进行中 |
| 全文输入基线 | 分层机制的质量与成本优势 | 进行中 |