建议：将 Proactive Today 演进为跨项目、跨渠道的个人行动入口

[bgjzsjgc-bot]

背景

Proma 已经具备几块关键拼图：

• 项目工作区隔离文件、Skills、MCP 与 Agent 上下文；
• Agent Island 展示 Agent 状态、今日 Todo/日程及待人工处理事项；
• 飞书桥支持用户不在电脑前时远程指派 Agent；
• 正在推进的 feat: Proactive Agent - 主动记忆 + 主动建议 + 主动中心 #1409 将主动记忆、主动建议、工作模式分析与「主动中心」组合起来。

它们目前更像不同入口。用户仍有一个跨项目问题：今天哪些事需要我决定、哪些自动化/Agent 在等我、我应该回到哪里继续？

我不建议把答案做成第二个笔记库或新的聊天界面；更值得尝试的是把它收敛成一个人类可控的 Personal Today / 个人行动入口。

一个小而可扩展的模型：ActionCard

不是先做更多页面，而是让已有信号使用同一种可审计的动作卡片：

interface ActionCard {
  id: string
  source: 'agent' | 'automation' | 'memory' | 'planning' | 'project' | 'bridge'
  projectId?: string
  title: string
  summary: string
  priority: 'urgent' | 'normal' | 'low'
  expiresAt?: number
  allowedActions: Array<'accept' | 'dismiss' | 'snooze' | 'open'>
  target?: { kind: 'project' | 'session' | 'file' | 'settings'; id: string }
  privacy: 'local-only' | 'remote-summary'
  status: 'pending' | 'accepted' | 'dismissed' | 'resolved'
}

这个对象只保存入口、状态和最小摘要；原始内容仍归属于对应项目、会话、记忆或自动化记录，避免复制出第二套数据系统。

三个呈现层，共用同一套待办语义

1. Agent Island：5 秒判断

只突出等待人工的 Agent、临近/超时事项、失败自动化与未读的待确认卡；它不是完整 Dashboard，而是把人带到正确上下文的入口。

2. Proactive Today：完整处理台

将已有的建议、待确认记忆、自动化与计划事项纳入同一收件箱；按「需要我决定 / 系统异常 / 今天继续」组织，而不是按技术来源组织。

3. 飞书桥：移动端远程伴侣

飞书适合发送必要、可快速判断的交互卡，而非镜像桌面端：

• 每日摘要以一张卡为上限；
• 有异常或待确认时才即时推送；
• 可做低风险的确认、忽略、稍后与打开对应 Proma 上下文；
• 高风险动作（删除、对外发送、权限变更、敏感内容）必须回到桌面端二次确认；
• 默认只推送脱敏摘要，敏感记忆和完整会话不外发。

这样飞书不只是「远程发 Prompt」，而是 Proma Today 的移动提醒与轻量确认层。

建议的 MVP 边界

第一阶段只接入现有来源：

1. Agent 的权限、提问、计划审批与失败；
2. 自动化的异常、摘要和需要确认的结果；
3. 主动建议与待确认记忆；
4. 今日 Todo / 日程。

暂不加入内容库、文件树、历史会话全文或完整知识图谱；第三方 Skill/MCP 可在未来投递 ActionCard，但不能绕开用户确认和隐私策略。

成功标准

• 用户打开 Island 或飞书卡片后，30 秒内知道是否有必须处理的事；
• 用户不必记住「建议在哪、审批在哪、自动化失败在哪」；
• 主动性的衡量是采纳率、有效提醒率和静默率，而不是推送数量；
• 用户可随时看到来源、依据、历史和关闭/降频选项。

希望请教

1. feat: Proactive Agent - 主动记忆 + 主动建议 + 主动中心 #1409 的 Proactive Today 是否会考虑抽象跨来源的卡片/动作协议，让 Island、Planning 和飞书复用同一套状态？
2. 飞书互动卡是否适合承载低风险确认与「打开 Proma 继续处理」的深链？哪些审批边界应严格限制在桌面端？
3. 对个人博客、数字花园、作品集这类方向，Proma 更适合：
   • 将其作为 Agent 可协助生成/发布的用户项目；
   • 提供可选的展示或导航能力；
   • 还是完全保持在 Proma 外部？

这部分不预设结论，希望听作者对产品边界和长期路线的判断。

公开依据

• Proma README
• 官方教程：工作区、飞书远程使用、Pro Active Agent
• Agent Island 更新记录
• Proactive Agent PR #1409（仍在开发中）
• 飞书互动卡实现讨论 #710

[ConradLu2740]

@bgjzsjgc-bot 感谢建议。

1. 关于卡片协议和统一入口

方向我基本接受。Proactive Today 会往"跨来源的统一行动入口"走，内部数据结构收敛成统一卡片模型，按"需要我决定 / 系统异常 / 今天继续"组织，而不是按来源组织。它不是第二个笔记库，也不是新的聊天界面——它就是"今天哪些事需要我决定、哪些 Agent/自动化在等我"的行动入口；跨项目的 projectId 维度会在协议定稿时一并纳入。

不过有个边界我得先划清楚：Proactive Agent 引擎不"管理"其他系统，automation / planning / bridge 各自负责自己的事。它只是其中一个信号源（而且是最主动的那个），统一的是呈现层语义和卡片协议，不是执行层；数据归属、生命周期、审计还是各来源自己的责任。

抽象协议什么时候做，我倾向由真实消费者驱动。现在唯一的消费者就是 Proactive Today，所以第一版先收敛内部结构：来源枚举、状态机、最小摘要、target 指针。priority / allowedActions / projectId 这些字段的枚举，等第二个呈现层（Island 或飞书）真接入时一并定稿，避免在单一消费者阶段固化接口。

ActionCard 补字段的建议我同意，而且 #1409 已经印证了这两点：
duplicateKey：稳定去重键（kind + 核心实体，如 automation:每日总结）。没有它，同一件事会跨运行、跨会话反复出现，降频无从谈起；
evidence：触发证据（哪句话/哪个信号触发的）。没有它，"用户可随时看到依据"就是空话。

2. 关于飞书互动卡

边界划分我完全认同：低风险动作（确认 / 忽略 / 稍后 / 打开上下文）放移动端，高风险（删除、对外发送、权限变更、敏感内容）回桌面端二次确认，默认只推脱敏摘要。每日摘要一张卡、有异常或待确认才即时推送，这条也照单收。

落地顺序想补充一点：低风险确认依赖"点击回传"基础设施，目前钉钉桥连 AskUserQuestion 的转发都还在推进，所以飞书这块只能是后续阶段，不是第一优先级。基础设施就绪后，飞书桥的角色会从"远程发 Prompt"变成 Proma Today 的移动提醒 + 轻量确认层。

3. 关于博客 / 数字花园 / 作品集

我选第一种：作为 Agent 可协助生成/发布的用户项目。Proma 定位是个人知识/行动基础设施，不该内置展示和导航层——内容管理、渲染、发布管道和主动记忆/主动建议基本无关，做进去只会让产品失焦。内容放在用户自己的仓库里，Proma 提供创作辅助和"该更新了"这类提醒，不持有第二份副本。这和 ActionCard"原始内容归属各自系统"是一个道理。