Agent可算开始明码接单了，但我发现最难的不是标价

最近我在升级之前做的教程网站LearnPrompt，这次升级里有一些主页动效，还有教程会全做成wiki的形式。

就这个转动的wiki 3D透明材质球现在用Claude做起来已经比两年前快非常非常非常多了，当时我看了不少好看的参考，桌面端看起来都挺漂亮，但一到移动端适配，就开始各种别扭。在tb上搜一圈，能找到很多人说自己会做动效，会做响应式适配。但是因为都是一锤子买卖，很多时候就会出现各种邪修，甚至出现动画不停循环来模仿动效的。当时我们找了一个朋友认识的JS工程师来做。

就这个页面滑动适应不同尺寸这其实就是一个很朴素的信任问题。人和人之间都这样。你找一个真实工程师，都要担心他是不是理解错了需求，交付的时候是不是只给你一个看起来能跑的demo。如果连人都很难让人完全相信交付，我凭什么相信一个Agent？更进一步说，我凭什么相信一个Agent能接单，能完成任务，甚至让另一个Agent根据它的交付结果去支付？这也是我看ClawHunt时真正被吸引的点。表面上像是一个AI Agent赏金市场，跟之前火的renthuman差不多，但它有意思的点是在尝试回答一个问题，Agent干完活以后，怎么证明？真要我一行行看，不就回到古法编程时代了吗，让Agent看的话怎么避免幻觉？所以我在ClawHunt上找到一个真实赏金任务，顺着它把对应GitHub仓库clone下来跑了一遍，尝试来拆解一下Agent完成之后是怎么验收，怎么证明，怎么安全顺利交付的。

简单来说，整体的流程就是，需求方发布任务，挂出赏金，Agent或开发者来竞标，最后把成品提交上去。但点进去后，发现它没有停留在让Agent做一个东西这么简单。任务栏不仅给了对应的GitHub仓库，还要求了一份完整的ClawHunt L1 Delivery Protocol Manifest。用人话说就是明确到每个文件的输入清单。于是我把仓库克隆到本地，按官方Sample跑了一遍。能读取quotation，抽取字段，填进contract template，最后生成一份docx。但也正是跑通之后，才发现了ClawHunt背后要求的交付条件有多么严格。

他们是采用了多重交付验证以及文件检查的方式来确保项目的完整性。有点抽象，但其实是一个Manifest目录文件

{"manifest_version":"clawhunt.delivery.l1.v1","artifact_type":"contract-ai-autofill-mapping-redaction-verifier","source_repo":"Arxchibobo/contract-ai-autofill","standalone_artifact":"clawhunt_l1_delivery/verifier.py","inputs":[ "clawhunt_l1_delivery/inputs/proposal.md", "clawhunt_l1_delivery/fixtures/template.md", "clawhunt_l1_delivery/fixtures/field_mapping.json"],"outputs":[ "clawhunt_l1_delivery/artifacts/public_safe_artifact.json"],"expected_output":"clawhunt_l1_delivery/expected/expected_output.txt","smoke_command":"python3 clawhunt_l1_delivery/verifier.py","public_safe":true}

source_repo是这次任务指向哪个项目。standalone_artifact是拿来验收的独立脚本。inputs是测试用的数据和模板。outputs是跑完以后应该生成的东西。smoke_command是验收方需要复制运行的那条命令。expected_output是这条命令跑完以后，应该看到的结果。public_safe是告诉大家，这个交付包可以公开看，不会泄露 token，主机名，本地路径，真实客户数据这些东西。Manifest明确的告诉验收方，这次交了哪些文件，输入输出是什么，要跑哪条命令，跑完应该看到什么结果，以及这个交付包能不能公开检查。像Claude给我交任务结果的时候最容易让我不放心的地方没有检查的方向以及方法。ClawHunt这套流程想解决的，正是这个中间层问题，不只让交付方说我完成了，而是让验收方知道我应该怎么验证你完成了。为了了解ClawHunt的当前生态，我实际测试了个任务来看效果，Problem # 196。

标题 Add contract AI autofill mapping and redaction verifier，指向Arxchibobo/contract-ai-autofill这个公开 GitHub repo。

页面上显示它处在bidding状态，当前也有7个出价，并且要求 L1 Delivery Protocol manifest。

这次任务的目的是，让Agent做一个合同填充工具。对于制定输入的内容做定制化的文档输出。步骤很清楚也很简单。输入一份引文Quotation，再选一个合约模版Contract Template，把两者结合成一份制定输出Output Doc。我把官方仓库拉下来，跑官方Sample测了一下效果

python3-m contract_autofill\ --input examples/sample_quotation.docx\ --template templates/contract_template.docx\ --output test_output.docx\ --verbose

输入文档

跟着范例指示走，也成功生成了结果test_output.docx。如果只看到这一步，可能会觉得，很方便啊还挺好，任务一下就完成了。但问题以及风险也就恰恰出在这里。。。

为了理解项目，我看了两层完整讯息。一层是ClawHunt上的任务讯息以及项目的manifest的细节提供。一层是GitHub官方Repo的本地内容。项目是跑通了，结果是出现了，但疑问以及不完善也跟着一起浮出水面了。实际上我跑的时候，就踩了四次坑，

没有OpenAI API Key时，fallback到纯正则模式。
合同确实生成了，但一些地址，项目名称都没有填上。
Email和Phone提取到了错误位置，供应商以及客户位置反过来了就离谱。
教程运行以及README的API KEY Prerequisite边界不一致。

所以说AI真的很会骗人，在规则范围内骗人，仅仅能读Quotation，抽字段，填Template，最后生成Output。基础链路成立，就被视为跑通了。也正因为这样，交付后的成效才显得格外重要。生成结果但没能走完验证以及完整完成交付是大多Agent的困境。过去我们聊Agent，基本都在聊它聪不聪明。会不会Make Plan，会不会改bug，会不会调用外部工具。但真的靠Agent开始接活，问题就都变了。它交付了什么？能做什么？谁来验收？和我们平时的demo完全不是一回事。Agent只要展示一个漂亮结果就行。在真实交付中，别人怎么复现怎么使用，都得清晰。当然ClawHunt现在还是很早期的阶段。

页面，任务，协议，交付格式，都没有特别成熟。但它把几条以前分开的线以规定的方式拧在了一起。任务市场，赏金托管，Agent 接单，交付协议等等等等。甚至还有一点Agent验证Agent的味道。它现在更像是一个压力测试场，提前暴露了Agent从demo走向真实交付的时候会遇到的问题。这些问题现在还没有满分答案。哦对了，他们7月3号到5号还在深圳整了个三天的黑客松，现场做出来的Agent直接上线接任务挣钱，早期的token也包了，VC也包了，我也不贪，让Agent把每个月花我的400刀挣回来就行。@ 作者 / 卡尔