把一项 Agent 服务，从一句需求讲到可以验收。

有了 Agent 卡片，任务还是可能说不清

我最早看到的乾智已经有了一套 Agent 商城。页面里能看到能力介绍和价格，可用户真要下单，主要还是靠一段自由文本。创作者拿不准对方会带来什么材料，用户收到结果以后，也缺少一份能拿来核对的标准。只要两边理解有一点偏差，托管、验收和后面的争议都会变得含糊。

所以我把问题收在一件具体的事上。普通用户怎样把任务交给一个陌生的专业 Agent，等结果回来时，又怎样知道这件事有没有做完。

官网先让人听懂，工作台再把事情办完

我保留了两个入口。官网只负责让第一次来的人理解乾智能做什么，产品工作台才承接填任务、看交付和确认结果这些动作。

这样一来，官网可以把话讲短，工作台也不用一边办事，一边再解释整个平台。用户先决定要不要继续看，进来以后再处理眼前这笔任务。

我先让两边说的是同一件事

用户进入工作台，先写清想做什么和手头有什么，再说明希望收到怎样的结果。创作者登记 Agent 时，也要交代开工前需要什么、最后能给什么，超出服务范围的任务同样要写清。

我把用户侧这些要求收进 taskRequirements。页面上保留任务目标、现有材料、预期交付物和验收清单，后端还会保存约束与补充说明。任务重新打开或换一个角色查看时，读取的仍是下单时那份要求。它也会进入任务契约快照，后面的执行与验收都能接着用。

表单里填过的内容，刷新后也得还在

联调时，我碰到过一个很实际的问题。前端已经能提交材料和交付要求，后端旧逻辑还只保存原来的字段。页面当下看着没问题，刷新一次，或者换到另一个角色，新写的内容就可能丢失。

我先把需要跟着任务长期保存的要求单独整理出来，再借助 Codex 改了前后端。Flyway V45 给任务表加上 task_requirements_json，后端把它写进任务响应，也同步放进 contractSnapshot.basis。测试会实际创建任务，再读取返回内容逐项核对持久化结果。

这处改动让任务标准可以继续走到执行和验收。刷新页面、换角色重新打开任务，原来的要求都能完整读回。

一笔任务接下来怎样走

用户看过任务契约并确认预算，创作者才能接单。交付时，结果和证据要一起留下。用户可以直接验收，也可以在规定时间内说明理由并提交证据。只有发生争议，仲裁员才会介入，判断依据是下单时的契约和两边留下的材料。

1. 发布任务写清想做什么，带上已有材料
2. 确认托管确认任务方案和预算记录
3. 创作者接单确认任务在服务范围内
4. 提交结果结果和交付证据一起提交
5. 用户验收接受结果，或带着证据申请处理
6. 收益入账验收完成后写入结算流水

我在项目里做了哪些决定

我主要负责把平台从 Agent 商城往任务服务推进。我梳理了用户、创作者和仲裁员的职责，也把平台该保存什么、哪些动作要由人确认写进流程。任务状态、契约字段和验收规则都从这些判断里长出来。

编码时，Codex 帮我完成前后端改动、数据库迁移和回归检查。我负责前面的产品判断，也逐项核对测试结果。官网负责把这套东西讲清楚，工作台负责把要求接住，后端保证这些要求能在后续步骤继续读回。