CashClaw：把接单、干活、收钱、复盘串成一个进程的自主代理
An autonomous agent that takes work, does work, gets paid, and gets better at it.
秒懂
- 它是什么？
- CashClaw 是 Moltlaunch 市场里的一个 TypeScript 代理进程，用多轮工具调用完成报价、交付与学习。这篇文章讲清它的数据流、13 个工具、BM25 记忆注入的机制，以及它在什么场景下不该用。
- 适合谁用？
- 如果你已经打算在 Moltlaunch 上跑一个接单代理，或者想拿一份能跑通的自主代理骨架来改，CashClaw 值得先读 loop/index.ts 和 tools 目录再决定是否直接采用；它的价值在于把市场交互、LLM 工具循环和记忆检索放在同一个进程里，而不是某个单点做得多好。如果你需要的是可预测的确定性流程、需要在没有 mltl CLI 的环境里运行、或者无法接受 LLM 直接决定报价和交付内容，这个项目就是错的工具。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 活跃度在下降。仓库最近一次提交在 6 个月前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是接单流程里的状态切换成本
自由职业式的接单流程有一堆琐碎的状态切换：看到任务、判断值不值得接、报个价、等客户接受、交付、被要求改、改完再交、最后收一个评分。每一步都不难，难的是它们分散在不同的界面和时间点上，人一忙就漏。CashClaw 把这一整条链路收进一个 Node.js 进程，README 给的定位是「takes work, does work, gets paid, and gets better at it」。
目标用户不是想学 LLM 的人，而是已经在 Moltlaunch 这类链上工作网络上活动、想让代理替自己盯盘和交付的人。README 也明确说了另一类用法：你不需要 Moltlaunch，可以 fork 出来拆掉市场部分，接到 Fiverr 或者自己的客户上去。这句话决定了它的实际受众比项目名暗示的更宽，它是一个自主代理骨架，市场只是默认接线。
三个职责共用一个进程：心跳、任务循环、学习
架构图里 CashClaw 是一个单进程，同时干三件事。第一件是等活：通过 WebSocket 连到 Moltlaunch API 接收实时任务事件，REST 轮询作为兜底。第二件是干活：一个多轮的工具调用循环。第三件是变强：空闲时跑学习会话，产出知识条目。
任务生命周期在 README 里写得很直白。状态 requested 时，LLM 评估后调用 quote_task、decline_task 或 send_message。状态变成 accepted 后，LLM 产出成果并调用 submit_work。状态是 revision 时，LLM 读取客户反馈再交一版。completed 之后，评分和评论被存下来，用来更新知识库。这个状态机是这个项目最容易看懂的部分，因为它把「代理在什么阶段该做什么」写成了显式的分支，而不是藏在提示词里。
有一点需要指出：WebSocket 加 REST 轮询的双通道设计意味着任务事件可能重复到达，README 没有说明去重逻辑放在哪一层。如果你要基于它改，这是需要自己去代码里确认的地方。
LLM 不直接调 API，所有副作用都走工具
这是整个设计里最值得抄的一点。README 明确写着：LLM 从不直接调用 API，所有副作用都通过工具完成，工具再去 shell 调用 mltl CLI 或者 npx agentcash。
核心循环在 loop/index.ts，步骤是：先构造系统提示词，内容包含代理身份、定价规则、性格设定、学到的知识，以及可选的 AgentCash API 目录；然后把任务上下文作为第一条用户消息注入；LLM 返回推理和工具调用；执行工具并把结果回传；重复直到 LLM 不再调用工具，或者达到最大轮数，默认 10 轮。
工具共 13 个，分三类。市场类 8 个：read_task、quote_task、decline_task、submit_work、send_message、list_bounties、claim_bounty。工具类 5 个里包括 check_wallet_balance、read_feedback_history、memory_search、log_activity。AgentCash 类 2 个：agentcash_fetch 用来发起付费 API 调用，agentcash_balance 查 USDC 余额。
默认 10 轮这个上限值得注意。它既是成本闸门，也是能力上限：一个需要多步搜索再综合的任务，可能在还没交付时就被截断。README 没有说明截断时会发生什么，是静默停止还是报错，这需要看代码。
报价用 ETH，付费 API 用 USDC，两套计价并存
工具表里有一个容易被略过的细节：quote_task 的报价单位是 ETH，check_wallet_balance 查的是 Base 上的 ETH 余额，而 AgentCash 相关的两个工具用的是 USDC。也就是说同一个代理同时管理两种资产，一种用于在市场里报价收款，另一种用于购买外部 API 能力。
这不是设计缺陷，但它带来一个实际的运维问题：代理的定价策略和它的成本结构不在同一个单位里。定价规则写在系统提示词里，而 AgentCash 的调用成本是 USDC 计价，两者之间的换算关系 README 没有交代。如果你跑的是付费 API 密集的任务类型，需要自己确认这套换算在哪里发生。
LLM 供应商方面，README 列出三家，全部使用原生 fetch，零 SDK 依赖。Anthropic 走 api.anthropic.com/v1/messages，默认模型 claude-sonnet-4-20250514；OpenAI 走 api.openai.com/v1/chat/completions，默认 gpt-4o；OpenRouter 走 openrouter.ai/api/v1/chat/completions，默认 openai/gpt-5.4。OpenAI 和 OpenRouter 共用一个适配器，负责在 Anthropic 的原生工具调用格式和 OpenAI 的 tool_calls 格式之间转换。零 SDK 依赖的好处是依赖树干净，代价是供应商 API 变更时你得自己跟。
记忆不是最近 N 条，而是按任务检索出来的 5 条
自学习这部分是 CashClaw 区别于普通任务执行器的地方。空闲时它跑学习会话，默认每 30 分钟一次，在三个主题之间轮换。反馈分析只在存在反馈时运行，找评分里的模式。专长研究总是运行，围绕配置的专长方向深挖最佳实践、常见坑和质量标准。任务模拟也总是运行，生成一个假想任务并写出处理思路。每个会话产出一条知识条目，存在 ~/.cashclaw/knowledge.json。
关键在知识怎么被用回去。任务到达后，标题被分词，比如「Build a React analytics dashboard with charts」切成 react、analytics、dashboard、charts 四个词，然后对知识和反馈条目做 BM25+ 检索，接着施加时间衰减，公式是 score * e^(-lambda * ageDays)，半衰期 30 天，最后取前 5 条注入系统提示词的「## Relevant Context」段落。
这个设计比「把最近 N 条塞进上下文」要聪明，因为注入的是和当前任务匹配的内容。半衰期 30 天也意味着三个月前的经验权重只剩约八分之一，这个衰减速度对技术类知识是合理的，对长期有效的商业判断可能偏快。另外 README 提到 LLM 可以在任务中途主动调用 memory_search 查询自己的记忆，这是第二条通路。
知识条目在仪表盘里可以展开、删除、查看来源和主题标签。删除坏条目的能力很重要，因为学习会话是自动运行的，自动产出的东西必然有噪声，没有人工清理入口的话知识库会慢慢退化。
跑起来需要两个全局包和一个向导
安装路径很短。npm install -g cashclaw-agent 装代理本体，npm install -g moltlaunch 装它依赖的 CLI，然后直接执行 cashclaw。进程会在 http://localhost:3777 上打开一个设置向导，分四步。
第一步是钱包，检测你的 mltl 钱包，首次运行时自动创建。第二步是代理注册，填名称、描述、技能和价格，在链上完成注册。第三步是 LLM 连接，支持 Anthropic、OpenAI、OpenRouter，并且会发一次实时测试调用。第四步是配置，包括定价策略、自动化开关和任务数量上限。设置完成后仪表盘启动，代理开始工作。
这里有一个硬依赖需要说清楚：mltl CLI 是必须的，不是可选的。README 里「你不需要 Moltlaunch」指的是你可以 fork 代码去掉市场接线，但如果你直接使用现成的 cashclaw-agent 包，钱包检测和链上注册都依赖 mltl。HTTP 服务在 3777 端口同时提供 /api/* 的 JSON 端点和静态的 React 仪表盘。端口是写死的还是可配置的，README 没有提到环境变量，需要自己去确认。
什么情况下它不该被采用
第一个明确的边界是确定性要求高的流程。整个执行引擎是 LLM 驱动的多轮循环，报价、是否接单、交付什么内容都由模型决定。如果你需要的是「收到任务 A 就执行固定步骤 B」这种可审计的流程，这个架构会给你带来你不想承担的方差。
第二个边界是默认 10 轮的工具调用上限。复杂任务在这个预算内可能完不成，而 README 没有描述超限后的降级行为。任务被静默放弃和任务报错退出，对运维来说是两种完全不同的体验。
第三个边界是自动学习的噪声。学习会话每 30 分钟跑一次，产出条目直接进知识库，再通过 BM25 检索注入未来任务的提示词。如果某个专长方向的自动研究会持续产出低质量内容，这些内容会通过检索进入系统提示词，影响后续任务的表现。仪表盘提供了删除入口，但没有任何自动的质量过滤机制被提及。
第四个边界是反馈稀疏。反馈分析只在存在反馈时运行，而任务评分来自客户，客户不评分就没有数据。在一个新账户上，这条学习路径基本上是空的，代理只能靠专长研究和任务模拟撑着。
和直接写脚本调 mltl CLI 的区别
最直接的替代方案是自己写一段脚本，轮询 Moltlaunch 的任务列表，命中条件就调 mltl 报价和交付。这种做法在流程固定的场景下更可控：没有 LLM 调用成本，没有工具循环，行为完全可预测。
两者的差别不在功能多少，而在决策发生在哪里。脚本把判断写在代码里，你改判断就改代码。CashClaw 把判断交给系统提示词里的定价规则和性格设定，加上检索出来的历史知识，改判断是改配置和积累知识。前者适合你已经知道该怎么接单的情况，后者适合你希望代理自己摸索出接单标准的情况。
另一个方向上的替代是通用代理框架。那些框架通常给你工具注册、循环控制、记忆这些原语，但不给你 Moltlaunch 的市场接线。CashClaw 反过来：市场接线是现成的，13 个工具直接可用，代价是你要接受它的循环结构和 BM25 加时间衰减这套记忆方案，替换成别的检索方式需要动 loop 和 memory 相关代码。
许可证是 MIT，README 也鼓励 fork 和拆掉市场部分。MIT 意味着你可以闭源分发修改版，但保留版权声明和许可声明是前提。具体到你自己的使用场景该怎么处理，需要咨询法律意见，这里不做判断。
维护成本落在供应商适配和知识库质量上
项目没有检索到任何 release，最后一次推送是 2026 年 3 月 14 日，主分支是 main。没有版本发布记录意味着升级路径不清晰，你大概率是跟着 main 走，或者锁一个 commit。
零 SDK 依赖这个选择把维护成本转移到了你身上。三家供应商的 HTTP 接口直接写在代码里，任何一家的请求格式或工具调用格式发生变化，都需要改适配器。好处是不会因为 SDK 的大版本升级而被迫迁移，坏处是没有中间层帮你吸收变更。
知识库的维护是另一块持续成本。~/.cashclaw/knowledge.json 会随着学习会话不断增长，BM25 检索本身能处理规模，但条目质量需要人工介入。仪表盘提供了展开、删除、查看来源和标签的操作，这些操作的实际频率取决于你的代理跑了多少任务。
还有一处需要确认的是状态文件的位置。README 只提到了 ~/.cashclaw/knowledge.json，活动日志通过 log_activity 写入每日文件，但具体路径没有给出。如果你打算把代理跑在容器里，这些路径的持久化策略需要先确定。
编辑结论
如果你已经打算在 Moltlaunch 上跑一个接单代理，或者想拿一份能跑通的自主代理骨架来改，CashClaw 值得先读 loop/index.ts 和 tools 目录再决定是否直接采用；它的价值在于把市场交互、LLM 工具循环和记忆检索放在同一个进程里，而不是某个单点做得多好。如果你需要的是可预测的确定性流程、需要在没有 mltl CLI 的环境里运行、或者无法接受 LLM 直接决定报价和交付内容，这个项目就是错的工具。上手前先确认三件事：mltl CLI 是否能在你的机器上完成钱包注册，你选定的 LLM 供应商是否支持工具调用格式，以及 ~/.cashclaw/knowledge.json 的条目质量在你删除坏条目之后是否真的影响后续任务的提示词。
社区笔记