从一个交付场景开始
假设你对 Agent 说：“帮我交付批量导出功能。要支持大数据量，不能泄露其他用户的数据；开发、测试和写说明可以继续，正式发布前让我确认。”
过一会儿，你最想知道的通常不是模型调用了多少次工具，而是：目标还差什么，谁正在做，哪些工作能继续，哪些必须等，以及凭什么相信已经做完。LoopX 的看板围绕这些问题组织信息。
本文用这个构造场景解释完整的基础模型。先读懂一张卡片，再看它如何成为可接手、可恢复的协作过程。最后回到 Agent-facing Kanban 的四个进阶问题。这里的 Kanban 指看板式协作界面，不是对整个 Kanban 方法的重新定义。
目标、任务、归属、门禁和证据有各自的身份与规则。看板把它们组织成列、泳道和详情；合法操作由控制面接收和验证。屏幕上的排列方式不会自行变成新的权限或新的事实来源。
一张图读懂基本对象
这些概念不是一组必须一次填完的表单。先有目标和工作项；协作、风险、并发或恢复需要出现时，再由对应的契约表达它们。一个本地单 Agent Goal 可以很简单，多 Agent 也仍然复用同一套基本对象。
| 概念 | 回答的问题 | 批量导出示例 |
|---|---|---|
| Goal · 目标 | 最终要达成什么，哪些约束不能丢？ | 交付可用、安全、可验证的批量导出。 |
| Acceptance · 验收 | 观察到什么，才能判断结果成立？ | 大数据量、权限隔离和使用路径经过验证。 |
| Todo · 工作项 | 下一块可交付工作或明确等待是什么？ | 实现导出、独立评审、集成验证、发布。 |
| Claim · 认领 | 目前由哪个 Agent 负责？ | 开发 Agent 认领实现，评审者认领评审。 |
| Lease · 租约 | 启用相应模式时，哪次执行在什么期限和范围内有效？ | 一次受控执行的 owner、有效期、版本和写入范围。 |
| Gate · 门禁 | 哪项决定或授权尚缺，具体挡住谁？ | 发布确认挡住发布，不自动挡住独立测试。 |
| Evidence · 证据 | 某个判断依据什么，适用于哪个版本？ | 候选修订 A 的测试结果、评审结论与产物引用。 |
| Lane · 工作通道 | 从当前 Agent 或操作者视角，工作被怎样分组和选择？ | 可推进、到期监控、等待决定、其他人负责。 |
| Shared Authority State · 共享权威状态 | 多人并发时，哪份受规则保护的状态算数？ | 共同认可的 Todo、claim、lease 及相应提交回执。 |
目标决定方向，工作项承载行动，认领表达责任，租约约束执行占用，门禁约束合法性，证据支撑判断。它们互相连接，但不能互相代替。
Goal 与 Todo：目标和当前计划要分开
Goal 是控制面的目标边界，有稳定的 goal_id，关联当前状态、工作项、约束和历史。一个 Git 仓库可以承载多个 Goal，一个目标也可以涉及多个仓库。仓库位置不应代替目标身份。
Todo 是 Goal 内的一项有身份的工作，使用 todo_id。标题“修一下导出”不够：接手者还需要知道具体行动、验收、依赖、负责人和允许的范围。修改标题不应让它变成另一个任务；方向改变时则应通过替代关系保留来龙去脉。
Goal：交付批量导出
验收：权限隔离正确；大数据量可用；用户能按说明完成导出
约束：允许开发与验证；正式发布需确认
Todo A：实现导出与基本测试
Todo B：独立评审候选修订，禁止原作者自审
Todo C：验证大数据量与权限边界
Todo D：发布已验收的候选版本，等待发布决定这是解释用的工作记录，不是可直接执行的 CLI payload。A 到 D 是当前计划，不是目标本身：如果评审发现更简单的方案，可以替代部分 Todo；目标和已确认的约束仍须保留。
多 Agent 时，per-Agent Vision 补充“这位 peer 当前负责哪个方向、有什么验收与重规划触发条件”。它是有界的执行方向记录，不是另建一个 Goal，也不是把某位 Agent 变成全局管理员。基础模型见 工作图、权限与 Peer 协作。
卡片、状态与 Lane：同一份工作，可以有不同读法
卡片正面适合放工作名称、优先级、负责人、关键等待、最新证据和下一步。完整依赖、历史、租约详情与失败原因放进详情。这样，人能快速判断，Agent 又能沿稳定身份展开事实。
不要把三种“分组”混为一谈：生命周期状态说明 Todo 是 open、blocked、deferred 或 done；工作类型说明它是推进、监控、门禁还是提醒；Lane则是面向某位执行者的分组、候选集合或调度路径。“开发中”“待评审”可以是领域展示列，不必成为 Kernel 的通用状态。被替代则通过 supersede 操作与 superseded_by 等关系记录，不额外创造一个通用状态枚举。
| 工作类型 | 用途 | 关键区别 |
|---|---|---|
advancement_task | 实现、研究、验证、文档或修复。 | 应产出可验证的结果，不限于写代码。 |
continuous_monitor | 按条件或节奏观察外部变化。 | 没有实质变化时保持安静，不把轮询次数当交付。 |
user_gate | 等待一项会阻塞相关工作的决定。 | 必须明确范围，不能只写“等用户”。 |
user_action | 提醒人处理一项事情。 | 提醒本身不授予权限，也不自动阻塞工作。 |
blocker | 记录缺少的执行条件及恢复路径。 | 未必需要人来解决，例如等待测试环境恢复。 |
同一张“独立评审”卡片，对开发 Agent 可能是“可见，但被排除执行”；对评审 Agent 才是“可认领”。被别人认领的工作仍可作为上下文出现，却不能因此被当前 Agent 接管。claimed_by、excluded_agents、依赖、能力、门禁和当前预算会共同影响执行候选。
因此，open 不等于 runnable，优先级高不等于能越过 Gate，出现在看板里也不等于当前 Agent 可以执行。Quota／scheduler 依据这些事实生成当前路由；可执行义务与建议分别由返回的契约说明。图与 Planning Horizon 负责帮助理解，不是第二个调度器。
Claim 与 Lease：责任归属和执行占用不是一回事
Claim：谁负责这张卡
Claim 通常体现在 Todo 的 claimed_by。它让其他 Agent 知道工作已经有人负责，也让状态写回能够检查行动者。它是软归属：不证明进程仍活着、不证明 Host 已绑定，也不是绕过权限的通行证。
普通生命周期操作要遵守当前 owner 与授权规则；必要的跨 owner 完成、重分配或替代，需要已有契约允许的明确委托。一个 Agent 被称为“管家”或“协调者”，不会自动获得修改所有 Todo 的权力。
Lease：哪次执行当前仍然有效
当 Goal 选择了相应的 hard-lease 协作模式，租约可进一步携带执行实例身份、TTL、版本和写入范围。续租要证明仍是合法持有者且版本匹配；到期、失效或旧版本不能被当作当前执行权。支持的操作还取决于所选 provider 和已经完成的迁移阶段。
读租约时，TTL 是有效时长，version 用于识别当前修订；epoch 可理解为一次执行占用的代次，用来分辨新旧执行者。Fencing 是写入前的校验：过期或失去资格的执行者，即使仍在运行，也不能凭旧身份提交受保护的写入。
当前 quota 不会自动消费 hard lease；是否采用租约，要看实际 Host 与执行路径的接入。可以有 claim 而没有 hard lease；也可以有有效 lease，却因为发布 Gate、能力缺失或预算边界而不能执行。租约只约束被接入这套 fencing 的路径，不能替所有外部系统提供“恰好执行一次”。旧执行器的停止与新执行器的启动，还需要对应 Runtime 的监督与恢复机制。
一个易错点是把“重放成功”看作“仍有权限”。幂等重放返回的是原操作的历史结果，不会自动续期。继续写入前要读取当前租约。现有 canonical lease renew 已明确支持 promoted 本地 File／SQLite 的续租；这不等于每个 provider 的 transfer、release、reclaim 和完整 Actor 生命周期都已经合格。
Gate 与依赖：准确地等，也准确地继续
依赖回答“事实是否已经成立”，Gate 回答“相关决定或授权是否已经具备”。测试环境未恢复、上游产物未到达，不一定需要人批准；发布需要确认，也不能靠多跑几轮监控来代替授权。
Gate 必须有作用范围。只阻塞一位 Agent 的决定，用对应 lane scope；只影响某项动作时，用具体 Todo 关联或 typed decision scope。真正暂停整个 Goal 才使用显式 global gate。goal-bound 这样的续接绑定并不自动代表全局阻塞。
发布 Todo 关联 production 决定；集成验证和说明文档若独立、已授权且其他条件满足，可以继续。把发布卡拖到“准备好”不会消费 Gate，用户的一句普通回复也不能被任意解释成发布批准。
同样要分清 dependency、successor 与 supersede。依赖是前置条件；successor 说明谁承接后续，不自动等于“必须等前项完成”；supersede 表示旧路线被新路线取代，不应把失效工作伪装成成功。等待条件可以绑定 Todo 完成、Monitor 的实质变化或其他支持的事件。
恢复时重新检查当前条件：修订可能变了，授权可能撤销，产物可能失效。相关规则见 Decision Scope、Todo Contract 和 任务关系投影。
Evidence：让“做完了”成为可以检查的判断
看板上的“完成”需要能展开理由。先区分三个东西：Artifact 是交付物，Evidence 是判断依据，Receipt 是某次操作被接受或观察到的记录。一份导出文件是产物；权限测试及样本核对是证据；“发布请求已提交”的回执只说明那个动作发生过。
| 问题 | 示例 |
|---|---|
| 验证对象是谁？ | 候选修订 A、对应 Todo 与这次执行。 |
| 做了哪种检查？ | 权限隔离负例、大数据量集成测试、独立评审。 |
| 结论和边界是什么？ | 通过、失败、未验证分别记录，写明适用输入与环境。 |
| 怎样展开与复核？ | 有权限的产物引用、运行记录、准确版本或摘要。 |
| 什么变化会使它过期？ | 代码、输入、依赖或授权发生了影响结论的变化。 |
“摘要里有一个 hash”“测试命令返回了 0”“Agent 发来一条消息”，各自能证明的事情有限。证据是否足以满足验收，需要领域验证和必要的独立判断；控制面负责保存身份、范围、结果与关系，不替人或验证器发明正确性。
在共享看板里放有权限的简要引用，原始日志、用户数据和私有文档留在授权的存储中。拥有一个引用不等于读过内容，收到材料不等于采纳，能读证据不等于能执行动作。Agent-scoped evidence ledger 提供有界的时间线与其他 Agent 的压缩 frontier，不是第二份任务数据库。
Shared Authority State：让所有参与者知道哪份状态算数
当两个 Agent 同时读取“无人认领”，或一位 Agent 在另一个 Host 上拿着旧状态返回，仅靠共享一张表不够。系统必须知道：谁有权提交、基于哪个版本、冲突时谁失败、操作已提交但响应丢失后如何恢复。
Shared Authority State 指共同遵守的权威状态与写入边界。它不要求把一切都塞进一个大数据库。Todo／claim／lease 的相应聚合有自己的 owner；Goal 意图、请求和返回、外部副作用也保留各自事务边界。跨边界通过明确关系和回执对账，不假装存在一个包住所有系统的事务。
共同事实，按版本提交
在已经支持的 canonical transaction 路径中，提交携带预期 revision。比较并交换（CAS）检查“我读取之后，有没有人先改过”；提交结果绑定事件与原操作回执。竞争者不能因为也看过旧卡片就覆盖新 owner。Lost response 则通过原操作身份恢复，而不是盲目执行第二次。
本地默认、provider 选择与 promotion 要分别读
LoopX 同时保留 legacy 路径和逐步迁移的 provider（状态提供方）路径。Promotion 指把某个 Goal 的权威来源正式迁移到选中的 canonical provider。未迁移的 Goal 仍遵守已有 Markdown／本地 writer 的权威规则；provider-first 调用没有 selector 时选择 File profile。选择 File、SQLite 或 PostgreSQL 的 provider，并不等于已迁移一个 Goal，更不等于自动获得跨主机写权限。
File／SQLite 已有具体事务和真实后端验证；SQLite 的完整连续运行资格、默认切换与 owner promotion 仍是单独边界。PostgreSQL 有 provider／service 接入契约及测试基础，认证服务、租户隔离、网络故障和跨主机运行要按对应 profile 验收。不能把“代码里有实现”直接写成“任意部署都已 ready”。
迁移后，所选 canonical provider 读空就按空处理，失败就明确报告；不能悄悄回退到旧 Markdown 或旧 lease 文件继续写。Markdown 仍可以作为可读投影保留，UI、缓存和同步到外部看板的行也仍是投影。更详细的来源边界见 Local Authority Provider 选择 与 Shared Authority RFC。
把这些对象串成一次完整协作
- 明确结果。Owner 提交批量导出的 Goal、验收和发布约束。工作被拆成有身份的 Todo；评审与实现的责任边界明确。
- 选择并认领。开发 Agent 读取当前可执行候选、认领实现工作。若所选模式要求 lease，再取得有效执行占用。Claim 成功后仍需检查环境、能力和授权。
- 执行并回写。实现产生候选修订与测试证据。失败或部分成功如实记录；一次 Turn 结束不自动代表 Todo 完成。
- 接手与验证。后继评审绑定候选身份和验收。评审者通过自己的准入与认领路径接手，读取产物并形成结论。登记接收者、投递消息和真实接手，是三个不同的事实。
- 处理等待。集成验证可继续；发布 Gate 只约束匹配的工作。若修订变化，旧评审不直接用于新候选，相关验证需要重新确认。
- 验收与返回。满足约定验收、得到必要发布授权后，按对应领域流程交付并回读结果。还有缺口就链接已有后继或重规划；完成结论要返回原来的受众。
这条路径展示的是各个能力如何配合，不表示当前存在一条“一键完成全部协作”的通用命令。Frontend、Lark、CLI 和实际 Runtime 的入口、接手与结果返回，必须逐条验证；注册人数也不能代替实际运行与验收。
怎样实际读一张 LoopX 看板
日常查看时，按这个顺序就够：先看 Goal 的验收缺口，再看当前 Agent 的工作通道；打开选中 Todo，确认 owner、依赖与 Gate；需要并发执行约束时查看 lease；最后展开证据和下一步。发现信息不完整，沿稳定身份查详情，不从“没显示”推断“不存在”。
下面是已连接 Goal 的查询入口。将占位符替换成真实、已注册的身份；源码开发从相应 worktree 使用 uv run --extra test loopx …，安装版直接使用 loopx。
# 当前目标与可展开的工作图
loopx --format json status --goal-id <goal-id> --include-task-graph
# 当前 Agent 视角的任务；任务身份不等于显示顺序
loopx --format json todo list --goal-id <goal-id> --role agent --agent-id <agent-id>
# 某个工作项的当前租约事实
loopx --format json task-lease inspect --goal-id <goal-id> --todo-id <todo-id>
# 当前 Agent 可见的有界证据时间线
loopx --format json evidence-log --goal-id <goal-id> --agent-id <agent-id> --thin --limit 20写操作通过当前 Todo、Gate、claim／lease 与运行契约提供的生命周期入口完成，不靠改展示列或拼一段状态文本。需要什么参数、是否要执行实例身份，以及当前能否继续，读取当前命令帮助和返回的动作契约。
CLI 与本地前端提供不同粒度的操作与读面；Lark 也有相应消息、目标通道和 Base 看板适配，但不能因此宣称所有界面字段和动作已完全等价。Lark Kanban adapter 目前仍标明 prototype contract：同步和触发需要配置，外部看板不自行创造另一套任务身份。
进阶一：状态迁移要成为可执行的契约
基础对象齐全之后，“开发中 → 待评审”就不只是一次卡片移动了。它需要说明交付修订、证据、评审工作和此后的修改边界。模型提出下一步，控制面检查身份、前置条件和相应权限，再记录接受或拒绝的结果。
LoopX 已将 Todo 完成、后继绑定和下一步更新组织成生命周期操作，见 Todo Next Action。业务上的“开发、评审、发布”由领域能力组织；不必把所有项目的业务列硬编码进 Kernel。
请求提交、执行成功、状态提交和用户收到结果仍是不同阶段。一次操作完成时，应能回答“现在共同事实是什么，下一位参与者怎样接手”，而不只增加一条活动记录。
进阶二：给 Agent 有界、可展开的决策上下文
把全看板和全部历史塞给模型，可能淹没当前限制；只返回“做下一项”，又丢失依赖和替代路线。Planning Horizon 提供当前任务附近的工作、关系、等待、验收缺口和少量可比较选项。
LoopX 的 Planning Horizon 是有界读模型。读模型要披露覆盖和截断，并允许按身份展开；它不应通过摘要顺序偷偷改变权限，也不能把局部视野当成全局状态。
评审者需要的是：“评审修订 A，当前测试通过但大数据量证据尚缺，开发者正在补验证，发布未授权。”这比完整聊天记录更贴近决策。建议仍是建议；机器要求的执行义务要在契约里明确表达。
进阶三：Todo 做完后，重新判断 Goal
PR 合并可能只完成实现，不代表用户已能使用批量导出。局部完成时，应明确链接后继、创建真正需要的新工作，或说明为什么无需后继；方向改变则保留替代关系。
任务链耗尽而验收仍未满足，需要 Replan；验收成立则应停止。LoopX 的 重规划结算 把写回绑定到具体完成身份或义务，不把“补一个只用于关闭流程的任务”当作进展。
No-follow-up 关闭的是当前续接问题，不是自动签发整个 Goal 的验收。消息被采纳、lease 被释放、Todo 被标记 done，也分别只证明对应那一层发生了变化。
进阶四：跨层恢复时，保留事实与边界
Runtime／Harness 提供执行和会话；控制面维护身份、状态与合法迁移；领域能力和模型组织路线与验收；看板把结果呈现给人和 Agent。好的接口让它们协作，不让任一层偷偷替其他层做主。
如果远端动作已发生而本地响应丢失，状态仍显示“待处理”不代表动作没做。应按既有幂等身份、回执和结果查询恢复；缺少确定证据时保留“不确定”。Lease 到期不会撤销已经发生的外部动作，重试也不能一概视作安全。
Shared authority 可以保护它自己负责的提交；跨代码仓库、发布系统和消息通道的流程仍需各自的效果与对账契约。完整分层与 Effect Program 见《从一次性 Agent 到长程控制面》。
怎样判断看板真的帮助了协作
- 两人同时认领：是否能确认谁成功，谁需要重新读取，而不是双方都以为自己有执行权？
- 旧执行者返回：已过期的租约、版本或来源能否被误用？未接入 fencing 的外部动作是否被明确标出？
- 评审版本变化：旧证据会不会被当成新版本已验证？
- 发布等待确认：Gate 是否挡住发布，同时允许独立且已授权的验证继续？
- 卡片完成或被替代：能否读回产物、验收缺口、后继和变更原因？
- 权威来源不可用：会不会偷偷回退到旧文件，产生两个 writer？
- 看板或历史被截断：能否发现还有未展示的工作，而不是错误宣布 Goal 完成？
这也是阅读能力状态的方法：把已发布的基础契约、可选模式、具体 provider 的已验证操作，以及仍需端到端验收的产品路径分开。本文固定到公开修订；相应版本的命令 readback 和 qualification 证据，决定某个部署能做什么。
一张有用的 LoopX 看板，应让人和接手的 Agent 一起回答：我们要到哪里，现在谁负责，什么可以继续，什么必须等待，依据是什么，下一步怎样被验证。基础对象提供共同语言，长程协作让这套语言跨过会话、中断和方向变化仍然有效。
实现与文档依据固定到 a96c9aa91。四张图与批量导出场景均为解释性合成示例，不是生产截图或效果数据。本文不宣称全部 Host、provider 与产品入口已经完成同等资格验证。