把 Agent 对话变成可以持续使用的项目跟进应用

一次项目讨论结束，Agent 整理出一份有用的摘要：落地页已经可以评审，移动端还需要检查，发布日期尚未确定。下周又产生一份新摘要。想知道当前谁负责、哪些决定还没做，就得重新翻两段对话。

一个小型项目跟进应用，可以给这些决定一个固定的位置。对话保留为来源，记录保存最新确认的状态，界面负责让人查看和修改。

本文是基于 1flowbase 已公开能力设计的实现方案，并非已提供的“聊天转项目”模板。你或 Agent 仍需配置数据模型、实现提取与审核流程、搭建界面。请先使用模拟数据，并核对所安装版本实际开放的能力。

从一个决定开始，不必搬进整段聊天

看一段虚构的对话：

• 用户：“落地页已经可以评审了。”
• Agent：“可以周五检查一下移动端布局。”
• 用户：“把移动端检查加进去，负责人和日期先留空。”

已确认的事项是“检查移动端布局”。负责人和截止日期仍然未知。周五只是建议，并没有成为约定；落地页可以评审，也不意味着移动端检查已经完成。

让 Agent 先提出一条小记录，在写入前展示给人审核。缺失值保持为空，同时保留来源引用。第一版的数据结构可以很简单：

项目：名称
跟进事项：
  所属项目
  标题
  负责人（可空）
  截止日期（可空）
  状态：待确认 / 已确认 / 进行中 / 已完成
  来源引用
  确认人 / 确认时间

这些字段需要你自己设计，并非产品内置字段名。来源应当能被有权限的审核者打开。如果聊天没有稳定链接，可以使用经过授权的导出文件标识和消息定位信息；不要编造永久链接，也不要把整段私人对话复制到任务标题里。

让确认过的记录有一个后端

当前 1flowbase README 说明了 Data Model 实体化 PostgreSQL 结构并生成带 OpenAPI 契约的 CRUD API，以及工作流自定义接口、原生 React 块和 MCP 操作能力。这些能力构成这个应用的基础。

创建并发布 Project 与 ActionItem 两个数据模型，建立关联。查看生成的 API 契约，不要猜测接口路径或请求字段。先通过受支持的 API 创建一条模拟事项，读取列表，再修改它的状态。

加入自动化之前，先确定更新规则：

• 为每条导入提议设置稳定的来源标识，并实现去重。重试同一次导入不应再生成一条任务。
• 修改前重新读取当前记录。如果 API 支持版本校验就使用它；否则自行实现冲突检查，把不明确的修改交回审核。
• 把任务状态与发消息、发布页面、付款等动作的授权分开。确认一条任务，并不等于授权它产生外部影响。

这些保护需要在应用中实现并测试。生成 CRUD API，并不会替你决定项目的审批规则。如果一个状态变化涉及额外业务逻辑，可以定义有明确输入输出契约的 Workflow Extension 并发布为自定义接口。权限和校验应在后端生效，也要测试绕过界面直接发起的请求。

为下一次对话准备一个界面

用原生 React/TSX 块搭建三个聚焦的视图：

1. 待确认队列：显示提议、来源和不确定的字段。
2. 项目事项列表：按状态筛选，同时让尚未分配负责人的事项容易被发现。
3. 详情页：确认负责人、修改日期，或把事项标记为完成。

界面对接应用开放的 API，并明确区分“建议值”和“确认值”。保存后重新读取记录；如果写入失败，保留草稿并展示错误，不要提前显示保存成功。

最直接的验收是关闭页面再打开，确认刚才的事项仍在。接着在另一个会话里修改它，检查第一个会话会不会静默覆盖较新的状态。通过这一步，跟进工具才真正能延续到创建它的那次聊天之后。

通过 MCP 持续维护应用

1flowbase 公开的发现流程是 mcp_list → mcp_get → mcp_call：发现能力、查看契约，再执行调用。获得授权的 Agent 可以使用开放的能力构建和操作应用，具体工具和权限取决于实例配置。

先给 Agent 一个范围清楚的任务，例如：“找出这个项目已确认但没有负责人的事项，提出需要追问的问题。”从只读开始。测试好行为和确认边界之后，再开放范围有限的写入操作。

对于后续对话，可以实现这样的流程：

读取已授权来源与项目当前状态
  → 提出带来源的修改建议
  → 澄清不确定信息，取得必要确认
  → 调用获准使用的应用能力
  → 回读记录，报告实际保存结果

MCP 提供工具接口，Agent 和应用仍需具备指令、调度、错误处理和确认逻辑。接上 MCP 本身不会启动后台工作，也不会自动把每段对话变成任务。

保留清楚的来源和权限边界

跟进事项只需要足以支持决定的上下文。避免复制凭据、私人客户信息或无关聊天内容。分别为原始材料和派生记录设置保留规则；原始来源过期时，应标记不可用，不要继续把失效链接展示成证据。

能查看项目事项的人，不应因此获得管理日志或所有对话的访问权。使用第二个受限身份测试权限。即使应用采用自托管，只要配置云端模型处理内容，相关数据仍然会发送给该模型服务。

第一版可以从手工选取的已授权片段开始。如果希望使用网关日志，先确认所安装版本提供了受支持、已授权的读取路径。运行复盘文章 单独讨论了这种证据访问问题。不要假定应用的 CRUD 密钥同时具有控制台日志权限。

跑通一个完整闭环

1. 按照官方安装说明，或在官网快速开始中选择操作系统。先部署测试实例，并记录版本。
2. 建立两个数据模型，通过生成的 API 验证一条模拟记录。
3. 用 React 块搭建审核与详情界面。
4. 按实例的 MCP 配置方式连接已授权的 Agent，查看可用工具契约。
5. 输入上面的虚构对话，验证负责人和日期在确认前保持为空。
6. 重复导入，在另一个会话修改事项，再用受限身份测试。先验证去重、冲突和越权拒绝，再使用真实项目数据。

第一个目标是一条已经确认、刷新后仍然存在、能在下一次对话里安全更新的事项。跑通之后，再围绕项目真正需要跟踪的决定扩展模型和审核流程。从源码仓库与产品文档开始，核对当前版本支持的能力。