乐观锁而不是悲观锁
智能体任务多为「读—算—写」，持锁期间在算会产生长事务。冲突推到提交时检查，读路径完全无锁。
代价：高冲突下频繁重试，界面要显示重试次数
◆
Main screen
黑板看板：状态、归属、版本三件事同时可见
任务卡上同时显示能力标签、版本号与依赖状态。版本冲突由乐观锁在提交时检出， 界面只负责把「谁改到了哪一版」说清楚。
设计稿说明：以下界面依据项目文档与压测报告重建，用于表达交互结构与信息层级； 面板中的并发、延迟与吞吐量均取自压测报告原文。
黑板（636 任务 / 142 智能体）
待分配
抽取年报中的关联交易条目
抽取长文本
依赖：—
核对条目与公告一致性
核对结构化
依赖：抽取 · 未满足
进行中
汇总条目生成表格
汇总表格
v3 · 持有者 A · 已 2 次重试
标注异常条目
判定规则
v1 · 持有者 C
完成
建立条目索引
索引
v5 · 已提交
生成任务拓扑
规划
v2 · 已提交
依赖关系做拓扑排序，有环的依赖直接拒绝——依赖倒挂会产出「看起来完成、实际不可用」的结果，比直接失败更难排查。
100 / 100并发全部成功
44.40 msAPI P95 最高值
7.47 ms批次耗时 / 请求数 @100 并发
9.82 msWebSocket P95
0.34 MB内存峰值
压测为自建脚本；条目创建历史样本为 22.7 / 21.8 / 19.7 entries/s，不是当前版本固定上限。
◆
Highlights
四个决定看板形态的判断
每一条都对应界面上一个「看起来更麻烦」的设计。
能力匹配而不是抢单
抢单会让「有能力但慢」的智能体拿不到任务，最终质量取决于谁反应快。任务按能力标签分配。
代价：要维护能力标签，分配比抢单慢一步
依赖必须拓扑排序
不允许「先做后补依赖」。有环的依赖直接拒绝，而不是产出看起来完成的结果。
代价：灵活性下降
压测结论上界面
并发、P95、吞吐量直接放在看板下方，和任务状态同源——不压测就不知道瓶颈在哪，也不知道该优化什么。
代价：多写一份压测脚本
◆
Detail
两个决定界面细节的判断
为什么任务卡要显示版本号
多智能体同时写同一块黑板，冲突是常态而不是异常。把版本号放在卡片上，用户一眼能看出是谁改到了哪一版。
- 提交时检查版本，冲突即重试，读路径无锁
- 界面因此必须暴露「重试次数」，否则无法判断是卡住还是正常
- 高冲突场景下这个数字会频繁变化，是预期行为
提交时的冲突检出
- v3 → v4 成功
- v3 → v4 冲突 · 重试 1
- v4 → v5 成功
- v4 → v5 冲突 · 重试 2
- v5 → v6 成功
为什么先核对并发指标的分母
旧报告将批次总耗时除以请求数称为平均延迟。并发请求会重叠执行，这个比值不能证明逐请求响应没有劣化；新版压测应分别记录吞吐和请求延迟分位。
- 10 / 25 / 50 / 100 并发的批次总耗时 / 请求数：7.73 / 7.41 / 7.89 / 7.47 ms；不是逐请求平均响应时间
- 历史写入样本约 20 entries/s；不能外推为当前版本或生产容量
- 界面并列展示，不做成一个好看的综合分
历史批次总耗时 / 请求数（ms）
单位为 ms；条形仅展示历史比值，不能当作逐请求延迟或据此判断响应稳定性。◆
Boundary
界面上明确不做的事
不隐藏重试
版本冲突导致的重试次数直接显示在任务卡上，不合并成「处理中」。
看起来不如「一次成功」干净
不接受到期补依赖
依赖未满足的任务停留在待分配，不允许先做完再补关系。
灵活性下降
不把估算当实测
写入约 20 entries/s 是 2026-09-06 的历史样本概括；当前批量提交版本尚待同环境复测。
数字不好看，但口径诚实