我的龙虾给自己写了一个 MCP Skill
我的龙虾跑了一个月,今天它给自己写了个Skill。
字面意思。
养
养龙虾不是养宠物,是养一个习惯。
装OpenClaw那天,我没想这么多。朋友说:”试试这个,比Claude Code开放。”十分钟装好,我开始用它查天气、读文档、改代码。
一个月后,我发现离不开它了。
真正的习惯不是”用了”,而是”开始嫌不够用”。
不够
我想知道每天哪些技术词在涨。
Agent、MCP、RAG、大模型……这些数据决定我写什么内容。但Notion处理时间序列数据很难受——查环比要翻半天,聚合分析更别扭。
换工具?试过几个,要么太重,要么不开放。
然后我想:既然龙虾能调MCP,为什么不能自己写一个?
它自己写的
我说:”想记录微信指数,要能存、能查、算环比。”
龙虾听完,自己查文档去了。
过一会儿,它说:”FastMCP不错,SQLite够用,我试试。”
又过一会儿:”数据模型写好了,Server搭起来了,Docker化也搞定了。跑在localhost:8000,你等等,我接网关。”
然后它自己写配置,自己对接,自己测试。
最后告诉我:”今天MCP指数110万,涨27%。你试试?”
我说试试。
它报数。正常。
全程我都没碰键盘。提需求,等结果,验收。
现在
每天早上,我问:”今天什么词在涨?”
龙虾翻它的数据库,告诉我:
- MCP:110万,↑27%
- Agent:95万,↑15%
- RAG:67万,↓3%
我扫一眼,决定今天写什么。
全程不超过30秒。
这意味什么
不是”AI会写代码了”这种老生常谈。
是我开始重新理解”工具”和”代理”的边界。
以前工具是我手里的锤子,我想砸哪砸哪。
现在龙虾更像一个实习生:我指方向,它自己跑流程,回来汇报结果。我不需要知道它怎么写的,只需要知道它写得对不对。
这种关系比”我用工具”轻,但比”我雇人”省。
下一步
龙虾说想再写一个:自动把微信指数数据同步到飞书多维表格。
我说行,你试试。
它去写了。
我继续写我的文章。
2026-04-09
模型正在变成水电(commodity),极低成本用一流模型只是表层红利;真正的护城河是模型 × 结构化上下文 × 编排(Harness)。以 Karpathy 的 Obsidian LLM Wiki 为入口,论证一人公司为何最终应把 Notion AI 立为 Agent 体系的核心知识底座,本地只留临时缓存。
用一件糗事开场:我让 AI 把几条零散进展扩写成周报,三天后连自己都信了它编出来的「下一步规划」。写的人尚且会被骗,天天看 AI 产出的人更不必说——生产端的成本塌了地板,消费端的判断力正在被一口口喂钝。全程第一人称,不替读者下结论。
手写 Prompt 的 Skill 一换模型就翻车,根因是我把措辞当源代码硬编码了。这篇复盘用 DSPy 重构的全过程:只声明契约和打分函数,措辞交给编译器自动生成;换模型重新 compile 一次,当初翻车的 case 全部跑通。
Anthropic 同时发布 Claude Opus 4.8 和 Dynamic Workflows,前者在编码基准测试上全面超越 GPT-5.5,后者让单个 Claude Code 会话能并行运行数百个子代理。这不仅是模型升级,更是 AI 工程范式的根本转变。
一句话结论:要让 AI Agent 真正驱动一套复杂的 ERP,关键不是”让 Agent 直接调接口”,而是分层封装——底层把接口收成一套干净 API(主干),往上逐层包成工具箱(MCP)→ 本事(SKILL)→ 领域专家(分身)→ 总管,再用触发器和任务让它没人盯着也能自己跑。 “要让外部的 AI Agent 跟 ERP 打交道,到底怎么接?”——这件事听起来很技术,但真正该想明白的,是技术管理者和业务负责人。这篇先把结论和全景图摆上来,再一层层拆开讲清楚。 一、结论先行:整套架构一张图 先看答案。下面这张图就是全部:一个请求进来后,沿着能力栈一层层走到 ERP;而旁边那排触发器,负责“没人点也能自动开工”。 flowchart LR USER["用户"] --> MAIN subgraph TRIG["触发(没人盯也能开工)"] direction TB TR1["定时任务"] TR2["事件触发"] TR3["手动"] TR4["上层调用"] end TRIG --> TASK["任务<br/>有状态 · 可重试 · 可后台跑"] TASK --> MAIN["① 总管 MainAgent<br/>统一入口 + 通用能力(作图 / RAG)"] MAIN --> SUB["② 分身 SubAgent<br/>领域专家 = 一个 L2 业务域"] SUB --> SKILL["③ SKILL<br/>一项本事 = SOP + 一组工具"] SKILL --> MCP["④ MCP Server<br/>工具箱 = L3 服务"] MCP --> API["⑤ API 封装层(主干)<br/>字段映射 / 认证 / 权限 / 保险"] API --> RAW["⑥ ERP 原生接口<br/>REST·OData / 业务函数 / 批量包"] RAW --> ERP["ERP 系统"] 两条线索读这张图: 能力栈(主干):用户 / 触发器 → 总管 → 分身(领域专家)→ SKILL(一项本事)→ MCP Server(工具箱)→ API 封装层(主干)→ ERP 原生接口 → ERP。每一层只做自己该做的事。 怎么被触发:定时、事件、手动、上层调用,都先生成一个任务,再由任务驱动那条链。 为什么非得分这么多层,而不让 Agent 直接调 ERP 接口? 因为直连会同时踩三个坑: 接口对人 / 模型都不友好:字段名是 A_PurchaseOrder 这种技术代号,认证、权限还得自己处理。 脏活要写很多遍:认证、权限、字段映射如果每个调用方各写一遍,以后行为还容易不一致。 工具一多就选不准:几百个原生接口直接丢给模型,它根本挑不对该调哪个。 下面每一层,正是为逐个解决这些问题而存在。我们从最底下的主干往上搭。 二、能力地图:先把 ERP 切成 L1–L5 ERP 的本质,是把财务、采购、生产、销售、仓库、人事全部装进一套系统,所有部门共用同一本账。要封装它,先得知道它的能力是怎么分层的——这张分层图是后面一切切分的基准。 ```mermaid flowchart LR ROOT[“L1 ERP 平台统一数据中枢”]