![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/8/8923e0ee67e006b40241c61f10b8c9a5440b1aa1.png\")
image2880×1508 435 KB
本周重点从离线评测和工具闭环，转向 Telegram 群内测、线上部署和真实使用反馈。目标不只是让 Bot 能在测试群里回答问题，而是观察它在真实群聊环境中的稳定性：是否会误触发、是否能隔离不同用户上下文、是否能正确检索官方文档和论坛资料、是否会过度追问，以及线上异常能否通过日志快速定位并修复。
\n本周关注的核心问题包括：
\n群聊中不同用户的上下文是否会互相串扰。
\nBot 是否会错误插入普通群聊。
\n用户连续追问时，系统是否能正确理解上文。
\n检索结果、引用和 source 选择是否稳定。
\nAgent 是否存在过度追问、答非所问、格式异常或无限重试等影响体验的问题。
\n多用户同时提问时，Telegram runtime 是否能并发处理。
\n用户上传文本文件或图片时，系统是否能把附件纳入回答上下文。
\n线上问题是否能通过日志、debug event 和回归测试快速定位。
\n本周开始在 Telegram 群中进行真实内测。测试不再只依赖人工构造的离线样例，而是让用户围绕 CKB、Nervos、Fiber、CCC、Agent 钱包、链上应用、游戏项目、新手学习路线和官方资料等主题进行自然提问和连续追问。
\n真实群测暴露出的行为比离线样例复杂得多：用户会用“它”“这个”“继续说”“有没有靠谱资料”“官方没有教程吗”这类短句承接上文；不同用户会在同一个群里交叉提问；用户也会直接纠正 Bot“你是不是回复错问题了”。这些反馈帮助我们把问题从“可能发生”变成“有日志、有复现、有测试”的工程闭环。
\n本周完成了 Telegram 群内短期记忆隔离改造，将上下文粒度调整为“群/频道 + 用户”。系统默认读取同一用户在同一群内最近 20 条与 Bot 相关的消息，并注入 full graph 作为短期上下文。
\n这样可以避免同一个群里 A 用户和 B 用户的对话互相污染，同时支持“我刚才问了什么”“继续说”“看看上文”这类短期追问。AskUser 的 checkpoint 恢复逻辑也同步改成按用户隔离，避免 B 用户误恢复 A 用户的补参流程。
\n群聊触发策略也进行了修复：
\n私聊直接响应。
\n群聊中只有被 @、被回复，或收到 Bot 命令时才响应。
\n普通群聊直接忽略，不发送 typing，不写入 memory，也不进入 graph。
\n这让 Bot 在群内的行为更自然：用户需要它时可以明确唤起，不需要时它保持安静。
\n内测中确认了一个重要运行时问题：如果 Telegram polling 串行处理所有 update，不同用户同时提问时会互相排队，复杂问题会明显拖慢其他用户。
\n本周将 Telegram polling gateway 改成多线程并发处理：
\n不同用户/会话可以并发进入 graph。
\n同一个 chat + user 的消息仍按顺序处理，避免同一用户连续追问乱序。
\nTelegram API 发送、debug event 写入和 feedback 写入增加锁保护。
\nSQLite memory 连接配置调整为允许多线程访问。
\n这部分没有采用多进程，避免引入额外的进程间状态同步和本地 Qdrant/SQLite 资源竞争。
\n服务器重启后曾出现一次严重线上问题：Agent 不断调用模型 API，但用户一直收不到回复。定位后发现根因不是模型，也不是网络，而是 Telegram sendMessage 返回 400 后异常向外抛出，导致当前 update 的 offset 没有推进。polling 下一轮又拿到同一个 update，于是同一条消息被反复处理，造成模型 API 被重复调用。
本周修复为：
\nsendMessage 失败后先从 MarkdownV2 降级为纯文本重试。
如果 reply 发送失败，再去掉 reply_to_message_id 作为普通消息重试。
process_update 失败也不阻塞 offset 推进，避免同一 update 无限重放。
补充发送失败、offset 推进和 fallback 发送的回归测试。
\n这项修复显著降低了线上 Bot 因 Telegram 格式或 reply 状态异常导致循环消耗模型调用的风险。
\n本周将 GitHub 文档库和 Nervos Talk 论坛数据接入当前 runtime，形成多库检索能力。系统启动时会加载多个 retrieval backend，并在日志中打印已加载的后端，方便确认线上运行环境是否接入了论坛库和文档库。
\n同时修复了论坛检索的超时问题。此前 discourse_query 会在大库上重建或扫描过多候选，导致线上工具调用超过 10 秒并被取消。修复后改为先通过 SQLite 做更小范围的候选预筛，再进行排序，从而让论坛检索能在服务器配置下稳定返回。
工具调用默认超时时间也从 10 秒延长到 60 秒，避免慢但有效的检索被过早取消。
\n真实对话中暴露出一个新的检索路由问题：用户问“有没有比较靠谱的资料可以看？”或“官方没有比较好的教程吗？”时，LLM 会自然生成 filters.source=official_docs，但当前数据库中官方文档实际 source 是 github_docs。这导致 qdrant_search 很快返回空结果，然后系统给出“知识库没有足够证据”的错误回复。
本周对此做了更稳的架构调整：
\n新增 retrieval source registry，统一定义当前合法 source。
\nplanner prompt 注入合法 source 和每个 source 的内容范围。
\n运行时对 LLM 生成的 filters 做 normalize 和 validation。
\n将 official_docs、docs、documentation 等别名映射到 github_docs。
对带 filter 的 qdrant_search 空结果，在预算允许时自动去掉 filter 重试一次。
广泛资料类问题优先走快速 vector search，避免无过滤条件下进入 BM25/fuzzy/exact 慢路径。
\n当前实际可用 source 包括：
\ngithub_docs：官方文档、docs.nervos.org、RFC、CKB/CCC/Fiber 仓库文档、SDK 文档和代码示例。
nervos_talk：Nervos Talk 论坛帖子、社区讨论、Spark/grant/proposal、生态项目介绍和真实案例。
这让 source 选择不再依赖模型猜测，也避免了模型生成不存在的 source 后直接导致检索为空。
\n本周对 full graph 中的 InfoGap、RetrieverPlanner、Reflection、DirectAnswer、AnswerComposer 等 prompt 进行了集中调整。
\n调优重点不是增加大量关键词规则，而是让 LLM 更清楚地区分：
\n哪些信息需要问用户；
\n哪些信息属于公开资料，应由系统检索；
\n什么时候应该基于合理默认假设继续回答；
\n什么时候应该说明证据边界，而不是泛泛拒答；
\n什么时候可以直接利用上文回答，而不是重新检索或重复追问；
\n用户在纠正 Bot 答非所问时，应直接道歉并重新聚焦，而不是继续检索旧问题。
\n同时，路由层增加了保护逻辑：
\nask_user 不再输出硬编码兜底回复。
如果没有真正的用户私有必填信息，graph 不应进入 ask_user。
post-answer reflection 如果把公开资料缺口错误路由到 ask_user，会被改路由到继续检索、改写或回答。
“你是不是回复错问题了”“答非所问”“不是这个问题”这类质量反馈会直接进入 direct answer，不触发资料检索。
\n这部分修复了“靠谱资料”追问被错误回复成 Fiber/testnet 默认假设，以及用户纠错后反而收到“知识库证据不足”的问题。
\n本周补充了 Telegram 附件处理能力。此前系统只能识别用户上传了文件或图片，但不会下载，也不会把内容交给模型。
\n现在支持：
\n文本类文件下载和内容注入，包括 .txt、.md、.json、.yaml、.csv、.log、常见代码文件和配置文件。
图片下载后保存本地路径，并在回答生成阶段作为 image input 传给支持多模态的 LLM。
\n对附件设置大小限制：文本文件 256KB，图片 20MB。
\n明确不支持 PDF，避免引入复杂解析和不稳定依赖。
\n这让用户可以在 Telegram 中上传日志、代码片段、配置文件或截图，让 Bot 直接基于附件内容回答。
\n为了支持群内测问题定位，本周补充了更完整的 debug 信息，包括节点耗时、LLM 调用摘要、检索证据数量、tool trace、reflection 决策、route decision、终止证据不足原因等。
\n同时补充了服务器部署相关支持：
\n增加 Linux 版 Telegram Bot 重启脚本。
\n调整 environment.yml，去掉 Windows 专属依赖，改成跨平台最小环境。
整理 .gitignore，避免提交真实配置、日志、群聊记录、周报、个人文档和缓存文件。
清理 GitHub 仓库历史，确保公开仓库不包含敏感信息和本地资料。
\n通过日志确认线上 bot 进程启动时间、加载后端和实际请求链路。
\n本周内测的主要价值，是让系统问题从“离线样例中可能发生”变成“真实用户已经遇到”。几个比较典型的反馈包括：
\n用户希望 Bot 能理解连续追问，而不是每轮都像重新开始。
\n用户不希望 Bot 插入普通群聊。
\n当用户说“我是萌新，你自己决定”时，Bot 应该主动给方案，而不是继续追问。
\n当用户问“有没有靠谱资料”“官方有没有教程”时，Bot 应该主动查官方文档，而不是给知识库证据不足。
\n当用户说“你是不是回复错问题了”时，Bot 应该识别这是对回答质量的反馈，而不是继续沿着旧问题检索。
\n技术回答需要稳定引用资料来源，否则用户难以判断可信度。
\n对代码示例类问题，即使证据不完整，也应给出清晰的骨架和边界说明。
\n响应时间需要继续优化，尤其是复杂问题经过多节点 graph 后等待时间较长。
\n用户希望可以上传文件、日志或截图，让 Bot 直接分析。
\n这些反馈说明，当前系统的核心挑战已经不只是“能不能回答”，而是“是否像一个可靠、不过度打扰、能持续理解上下文、能使用资料和附件的群内助手”。
\n本周围绕 Telegram 群内测暴露的问题补充和运行了多组回归测试，重点覆盖：
\n群内同用户上下文读取。
\n不同用户记忆隔离。
\nAskUser checkpoint 按用户恢复。
\n群聊 mention-only 触发策略。
\n未触发消息不写入 memory。
\n多线程并发处理与同一用户消息顺序保证。
\nTelegram sendMessage Markdown/plain/detached fallback。
offset 在异常场景下仍推进，避免同一 update 无限重放。
\n多库检索、论坛检索性能和工具 60 秒超时。
\nqdrant_search broad resource 查询优先 vector path。
source registry 注入、source alias 规范化和空结果 fallback。
\nresponse-quality feedback 直接回复，不进入检索。
\npost-answer ask_user 防护和 ask_user 硬编码兜底移除。
Telegram 文本文件下载、内容注入和图片作为 LLM image input。
\nCSAT、feedback、BadCase 逻辑回归。
\n阶段性相关回归测试结果为：
\n\n192 passed, 2 warnings\n\n后续需要把本周真实群测 bad case 继续沉淀为标准评测样例，避免类似问题再次回归。
\n本周完成后，系统从“群内可测”进一步推进到“线上可诊断、可修复、可回归”。主要成果包括：
\nTelegram 群内测开始形成真实反馈闭环。
\n群内上下文实现按用户隔离。
\nBot 在群聊中默认只响应明确触发，减少打扰。
\n不同用户问题可以多线程并发处理。
\nGitHub 文档库和 Nervos Talk 论坛库进入 runtime 检索路径。
\n检索 source registry 和 filter 校验让资料检索更稳定。
\n过度追问、回答滞后、答非所问、引用缺失、Markdown 异常等真实问题得到系统修复。
\nTelegram 发送失败不再导致 update 重放和模型 API 无限调用。
\nTelegram 文本文件和图片开始进入模型上下文。
\nDebug 日志和部署脚本更适合线上排查。
\n响应延迟仍需要优化。复杂问题经过多节点 graph、检索、反思和回答生成后，耗时仍偏长。
\nPrompt 仍需要根据真实内测继续调优，特别是“主动给默认方案”和“避免编造”之间的平衡。
\n引用稳定性还需要继续观察，尤其是连续追问、资料链接和代码示例场景。
\nsource registry 目前是静态配置，后续最好从实际 archive metadata 自动生成或定期校验。
\n附件支持目前覆盖文本文件和图片，暂不支持 PDF、音频转写和复杂 Office 文档。
\n内测反馈还没有形成结构化问卷和统计指标，目前仍偏人工观察。
\n部署流程还可以继续标准化，例如补充 systemd、健康检查和日志轮转。
\n下周重点不再是继续堆功能，而是围绕 Telegram 群内测反馈做系统调优、用户评估设计和线上运行稳定性提升。
\n将过度追问、回答滞后、引用缺失、上下文误用、检索为空、答非所问、发送失败等问题归类，形成可复盘的 bad case 列表。
\n重点优化小白问题、连续追问、代码示例、公开资料检索、默认假设选择和证据边界说明。
\n让 planner 更稳定地理解 github_docs、nervos_talk 等 source 的内容范围，并考虑从 archive metadata 自动生成 source 提示，减少手工维护。
设计一份简短问卷，用于收集用户对回答质量、上下文理解、响应速度、引用可信度、追问体验、附件分析能力和整体可用性的主观评价。
\n初步统计满意度、常见失败类型、用户是否需要重复解释上下文、是否认为 Bot 打扰群聊、是否愿意继续使用等指标。
\n把真实群测中暴露出的典型问题转成可重复运行的评测样例，形成“内测反馈 → 测试集 → 回归验证”的闭环。
\n基于 node timings 和 LLM trace 分析耗时瓶颈，优先优化简单问题、常见追问和资料类查询的快答路径。
\n在现有重启脚本基础上，补充更稳定的守护方式和日志观察流程，降低内测期间人工维护成本。
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10232, "title": "当 84% 的开发者都在用 AI Coding，CKB 开发者体验的下一步怎么走？（附完整调研与路线图）", "slug": "84-ai-coding-ckb", "url": "https://talk.nervos.org/t/84-ai-coding-ckb/10232", "created_at": "2026-05-06T13:07:08.610000+00:00", "last_posted_at": "2026-05-06T13:07:08.768000+00:00", "category_id": 32, "tags": [], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24150, "post_number": 1, "topic_id": 10232, "topic_title": "当 84% 的开发者都在用 AI Coding，CKB 开发者体验的下一步怎么走？（附完整调研与路线图）", "topic_slug": "84-ai-coding-ckb", "author": "yixiu.ckbfans.bit", "created_at": "2026-05-06T13:07:08.768000+00:00", "updated_at": "2026-05-06T15:29:10.710000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/84-ai-coding-ckb/10232/1", "content_text": "摘要： AI 辅助编程现已成为软件开发的主流，84% 的开发者已将 AI 工具融入工作流。本报告系统性地审视了这一趋势下 CKB 生态在 AI 覆盖上的现状与差距——从开发者工具选择、AI 检索机制、到 Solana/Ethereum 的 AI First 最佳实践对标分析。核心发现包括：CKB 在 AI 可消费性上存在严重缺口（无 llms.txt、无官方 MCP、无 Skills等），Context7 代码片段量仅为竞品链 SDK 的 1/22–1/41；同时 Bolt.new 上的实测也表明，AI 工具已具备基础 CKB 编程能力，但在高级场景中仍会出现幻觉或功能性错误 。这不是一个可行性问题，而是一个准确性和丰富度的问题。结合以上信息最终给出我们认为最有价值的改进建议。\n以下是完整报告。\n目录\n1. 开发者 AI 编程习惯现状\n2. AI 处理开发者问题的检索习惯与流程\n3. Solana 与 Ethereum 的 AI First 实践与成效\n4. CKB 在 AI 平台上的现有覆盖评估\n5. 改进建议与行动计划\n6. 实施路线图\n附录\n1. 开发者 AI 编程习惯现状\n1.1 宏观数据\n84% 的开发者 使用或计划使用 AI 编程工具（2025 Stack Overflow 开发者调研）。其中，51% 的专业开发者每天使用 AI 工具，另有 17.7% 每周使用。\n41% 的代码 由 AI 生成或辅助完成。\nGitHub Copilot 活跃用户中，46% 的代码 由 AI 贡献（2022 年发布时仅为 27%）\nimage2880×1508 435 KB\n1.2 主流工具分类与市场格局\n开发者使用的 AI 编程工具可归为四大类：\n类型\n代表工具\n特点\n市场地位\nAI 原生 IDE\nCursor, Windsurf, Google Antigravity 等\n从零构建，AI 作为核心交互层；全项目上下文感知；深度 Agent 能力\n增长最快，Cursor 估值约 $50B\nIDE 插件/扩展\nGitHub Copilot, Cline, Augment Code, Amazon Q\n集成到现有编辑器（VS Code / JetBrains）；尽可能延续开发者现有工作流\n用户量最大，Copilot 用户超 2000 万\n终端/CLI Agent\nClaude Code, Aider\n命令行操作，无 GUI；自主性最强；适合复杂架构任务\n技术深度型开发者偏好\nWeb 平台\nBolt.new, Replit\n浏览器内运行，无需本地环境；适合快速原型和非开发者\n入门级 / 原型场景\n1.3 开发者工具选择的关键趋势\nAgent 模式成为标配 ：到 2026 年初，所有主流工具都已具备某种程度的 Agent 能力（自主推理、拆分子任务、执行代码、运行测试、自我纠错）。\n全项目上下文是核心竞争力 ：开发者最看重的技术标准是，工具能否理解整个项目，而非仅当前打开的文件。Cursor 与 Windsurf 的全代码库索引能力正是其核心卖点。\n多工具并用是常态 ：开发者可能用 Claude Code 处理复杂架构，用 Cursor 进行日常编码，再用 Copilot 完成快速补全。这意味着需要适配多种工具。\nMCP（Model Context Protocol）快速普及 ：MCP 是连接 AI 助手与外部数据源的开放标准，由 Anthropic 于 2024 年 11 月发布，已被 OpenAI、Google、Microsoft 等主流厂商采纳。截至 2025 年底，MCP 服务器累计下载量已超过 800 万，生态内服务器数量超过 5800 个。\n1.4 开发者评估 AI 工具的六大标准\n上下文窗口与代码库理解能力 ——能否理解整个项目。\nAgent 深度 ——是只能建议代码片段，还是能自主编写、测试、修复并提交。\n模型灵活性 ——是否绑定单一 AI 服务商。\n定价模型 ——订阅制 / 按量付费 / 自有密钥付费。\n编辑器集成 ——是否需要迁移现有工作流。\n企业合规 ——SOC 2、数据驻留等。\n1.5 对 CKB 目标开发者的启示\nCKB 的目标开发者群体（Web3 原生 + Web2 转型）在使用 AI 工具时呈现出不同的特点：\nWeb3 原生开发者 ：倾向使用 Cursor / Windsurf 等 AI 原生 IDE，重度依赖 Agent 模式处理复杂的链上逻辑；也会使用 Claude Code 等终端工具来应对底层架构。\nWeb2 转型开发者 ：更多使用 GitHub Copilot（学习成本低），依赖 AI 来弥补区块链知识差距；对文档检索和代码示例的依赖度极高。\n2. AI 处理开发者问题的检索习惯与流程\n2.1 AI 编程助手的分层检索机制\n当开发者向 AI 提问时（如\"如何在 CKB 上创建一个转账交易？\"），AI 按以下优先级检索信息：\n第 1 层：项目本地上下文（最高优先级）\n├── 项目配置文件（CLAUDE.md / .cursorrules / AGENTS.md 等）\n├── 当前打开的文件 & 最近编辑的文件\n├── 项目依赖（package.json / Cargo.toml 等）\n└── 全代码库向量索引（语义搜索）\n↓\n第 2 层：MCP 服务器（外部结构化数据源）\n├── Context7 MCP — 9000+ 库的实时文档检索\n├── DeepWiki MCP — GitHub 仓库的 AI 文档\n└── 自定义 MCP 服务器\n↓\n第 3 层：AI 模型训练数据（内置知识）\n├── 公开文档、教程、Stack Overflow 等\n└── GitHub 公开仓库代码\n↓\n第 4 层：Web 搜索（实时补充）\n├── 搜索引擎结果\n└── llms.txt / llms-full.txt 文件\n2.2 各检索层的详细工作原理\n第 1 层：项目本地上下文\nAI 编程助手会首先索引开发者的整个项目：\n向量化索引 ：Cursor 将整个项目编码为向量存储，Windsurf 的远程索引引擎可处理超大代码库。\n项目规则文件 ：这是开发者向 AI 注入项目特定知识的关键入口。\n配置文件\n适用工具\n格式\nCLAUDE.md\nClaude Code\nMarkdown，支持 5 层继承\n.cursorrules\nCursor\n纯文本/Markdown\ncopilot-instructions.md\nGitHub Copilot\nMarkdown\n.windsurfrules\nWindsurf\n纯文本/Markdown\nAGENTS.md\nOpenAI Codex/ChatGPT\nMarkdown\n第 2 层：MCP 服务器\nMCP 的工作流程如下：\n请求检测 ：AI 分析开发者的 prompt，识别涉及的库或框架。\n文档检索 ：MCP 服务器查询其索引的文档数据库。\n智能排序 ：通过排名算法筛选最相关的文档片段。\n上下文注入 ：将检索到的文档注入 prompt 的上下文窗口中。\n生成响应 ：LLM 基于最新、准确的文档生成代码。\nContext7 的工作方式 ：\n为超过 9000 个库的文档和代码示例建立索引。\n通过 resolve-library-id 和 get-library-docs 两个工具向 AI 客户端暴露数据。\nCKB CCC 库已收录于 Context7，包含 141 个代码片段，基准分 85.1。\nDeepWiki 的工作方式 ：\n为 GitHub 仓库自动生成 AI 驱动的交互式文档。\n通过 MCP 提供 read_wiki_structure 、read_wiki_contents 、ask_question 等工具。\nCKB CCC 已有完整的 Wiki 结构（六大章节，覆盖核心层、集成层、钱包集成、协议扩展等）。\n第 3 层：训练数据\nAI 模型的训练数据有时效性问题。对于 CKB 这样的小众链，训练数据中的 CKB 信息量远少于 Ethereum/Solana。这使得第 1、2 层的信息供给尤为关键——如果这两层没有足够准确的信息，AI 就会用训练数据里有限且可能过时的知识来\"推断\"答案。\n第 4 层：llms.txt 标准\nllms.txt 是一个新兴标准（类似 robots.txt），以 Markdown 格式提供网站内容的结构化摘要。\nllms-full.txt 则包含完整内容，供 AI 模型直接消费。\n已被 Vercel、Anthropic、Windsurf（Mintlify）等采用。\n可将 AI 获取文档时的 token 消耗降至十分之一。\n2.3 AI 处理开发者问题的典型流程\n开发者提问：\"如何用 CCC 在 CKB 上创建一个 UDT 转账？\"\n↓\n[1] 分析意图：识别关键词 CCC / CKB / UDT / 转账\n↓\n[2] 搜索本地上下文：检查项目依赖与现有代码\n↓\n[3] 查询 MCP 服务器：Context7 获取 CCC 文档 / DeepWiki 获取仓库架构\n↓\n[4] 补充训练数据中的 CKB 知识\n↓\n[5] 信息仍不足 → 触发 Web 搜索\n↓\n[6] 综合上下文，生成代码答案\n↓\n[7] 验证与迭代：自动运行 / 检查错误 / 修复\n关键痛点 ：如果在第 2–4 层都找不到足够准确的 CKB 信息，AI 极易产生“幻觉”——生成看似合理但实际错误的代码，这将严重损害开发者对工具的信任和开发效率。\n3. Solana 与 Ethereum 的 AI First 实践与成效\nSolana 和 Ethereum 是目前在 AI First 开发者体验方面投入最大、成效最显著的两条链。\n3.1 Solana：AI First 的标杆\nSolana 基金会已将 AI 辅助开发确立为一等战略 ，构建了业内最为完整的 AI 开发者工具链。\n3.1.1 官方 Solana Developer MCP（mcp.solana.com）\nSolana 基金会维护的官方 MCP 服务器，可直接集成到 Cursor、Windsurf、Claude Code 等 AI IDE 中：\n实时文档检索 ：自动查询 Solana 和 Anchor Framework 最新文档。\n账户查询 ：直接查询链上账户信息。\n交易分析 ：解析交易详情。\nCPI 语句生成 ：自动生成跨程序调用代码。\n部署方式 ：公共服务，地址为 mcp.solana.com/mcp，开发者仅需一行配置即可使用。\n3.1.2 AI Coding Skills 生态\nSolana 提出了 “Skills”模式 ——一套精心编写的指令集，旨在教会 AI 如何成为 Solana 专家开发者。这是极具创新性的做法：\nSkill 名称\n维护方\n覆盖领域\nsolana-dev-skill\nSolana Foundation\n端到端 Solana 开发：钱包连接、Anchor 程序、测试、安全\nhelius-phantom-skill\nHelius Labs\n前端 dApp 开发：React/RN + Phantom Connect SDK\nmetaplex-skill\nMetaplex Foundation\nNFT 开发：Core NFTs、Candy Machine、Umi/Kit SDK\nsolana-anchor-claude-skill\nQuickNode Labs\nAnchor 合约开发 + 测试（LiteSVM）\nsolana-game-skill\n社区\n游戏开发：C#、React Native、Unity SDK\nsolana-skills-plugin\n社区\n安全审计 + ZK Compression + 漏洞检测\npinocchio-skill\nSendAI\n高性能 Solana 程序（可减少 88-95% 计算单元）\nvulnhunter-skill\nSendAI\n安全漏洞检测与变体分析\nSkills 的关键特点 ：\n模型无关 ：兼容 OpenAI API、Claude API、Cursor Rules、ChatGPT 自定义指令。\n可组合 ：Skills 可以叠加使用。\n社区贡献机制 ：通过 TypeForm 提交新 Skill，形成开放生态。\nSKILL.md 标准 ：便携式技能文件，可被任何 Agent 框架加载。\n3.1.3 Helius 生态工具链（基础设施商的典范）\nHelius 作为 Solana 的基础设施商，构建了完整的 AI 开发者工具套件：\n工具\n功能\n规模\nHelius MCP Server\n结构化 API 调用（getBalance、parseTransaction 等）\n60+ 工具\nHelius Skills\n专家指令集（Build / DFlow / Phantom / SVM）\n4 大领域\nHelius CLI\n命令行工具，支持 --json 输出\n95+ 命令\nClaude Code Plugin\n一键安装，集成 MCP + Skills + 参考文件\n全家桶\n安装仅需一行命令：\nclaude mcp add helius npx helius-mcp@latest\n3.1.4 awesome-solana-ai 策展仓库\nSolana Foundation 维护的 awesome-solana-ai 仓库，系统性收录了：\nAI Coding Skills ：10+ 官方/社区 Skills（通用、DeFi、基础设施）。\nAI Agents ：12+ 链上 AI Agent 框架（Solana Agent Kit、Eliza、GOAT 等）。\nDeveloper Tools ：15+ 款 AI 增强开发工具（MCP 服务器、审计工具、IDE 等）。\nLearning Resources ：学习资源汇总。\n3.1.5 官方 AI 开发指南\nSolana 官方文档站（solana.com）设有专门 AI 开发入门指南，涵盖：\n如何在 IDE 中配置 Solana MCP。\n如何利用 AI 工具构建 Solana 应用。\nAI Agent 开发框架介绍。\n最佳实践。\n3.2 Ethereum：生态驱动的 AI 友好化\nEthereum 虽未像 Solana 那样由基金会统一推动 AI First 战略，但凭借庞大的生态和社区，其 AI 可消费性已相当成熟。\n3.2.1 llms.txt 标准的先行者\nEthereum 核心库已全面采用 llms.txt 标准：\n项目\nllms.txt\nllms-full.txt\nwagmi.sh\n/llms.txt\n/llms-full.txt\nviem.sh\n/llms.txt\n/llms-full.txt\nwagmi 在首页醒目位置展示了 AI 友好标识：\"Are you an LLM? View /llms.txt for optimized Markdown documentation, or /llms-full.txt for full documentation bundle \"。\nimage1920×940 232 KB\n3.2.2 Context7 上的压倒性覆盖\n以 viem（Ethereum TypeScript 接口库，在 CKB 生态中可与 CCC 类比）为例：\n指标\nviem (Ethereum)\nCCC (CKB)\n差距倍数\nContext7 代码片段数\n3,090 - 5,827\n141\n22x - 41x\n基准分\n90.35\n85.1\n1.06x\n来源信誉\nHigh\nMedium\n—\nllms.txt 独立索引\n（单独条目）\n—\nviem 在 Context7 上拥有多个索引条目（GitHub 仓库 + llms-full.txt + 文档站），总代码片段数超过 10,000 ，而 CCC 仅有 141 个。这意味着 AI 在生成 Ethereum 代码时拥有 70 倍以上 的参考素材。\n3.2.3 专属 MCP 服务器\nEthereum 生态已有多个专属 MCP 服务器：\nViemCP ：专为 viem & wagmi 构建的 MCP 服务器\n内嵌代码模式（零延迟，离线可用）。\n链上数据查询（余额、交易、合约状态）。\nwagmi React hooks 代码生成。\n实时文档访问。\nOnChains Dev MCP ：聚焦 viem 与 wagmi 文档的轻量级 MCP。\nEVM MCP Tools ：通用 EVM 链交互工具。\nRemix IDE RemixAI ：Solidity 智能合约的内置 AI 助手与 Copilot。\n3.2.4 丰富的 AI 配置模板\nEthereum 社区在 GitHub 上已有大量 Solidity/.cursorrules 模板流传，覆盖：\nSolidity + Hardhat 开发。\nSolidity + Foundry 开发。\nReact + wagmi + viem 前端开发。\nOpenZeppelin 合约模式。\n3.2.5 AI Agent 生态\nEthereum 在生态构建方面更进一步，其开发者门户（ethereum.org）已设有两个专门的策展页面：\nimage2290×1422 161 KB\n“Build onchain with agents” 专区，为 AI 代理堆栈提供结构化的以太坊知识。\nAI Agents 专题策展页面 ，系统性地介绍链上 AI Agent 生态。\n同时，社区还维护着 ETH Skills，这是一个专门为 AI Agent 提供实时以太坊开发文档的知识库，内容涵盖 Gas 成本、Solidity 模式、Layer 2、DeFi 组合性、安全、测试与生产部署等关键领域。\n3.3 其他链的 AI First 速览\n除了 Solana 和 Ethereum 的深度布局，越来越多的公链已直接将“Ask AI”或类似的文档查询助手内建至开发者门户。纵观它们的实践，将文档对内对外全面“打开”，已成为一种无需言明的新标配 。以下列举了其中一些链的主要动作：\n链\n核心工具/功能\n亮点 / 当前状态\nBNB Chain\nMCP、Ask AI MCP （IDE 内文档查询）\n推出了以 MCP（模型上下文协议）为基础的专门服务。\nPolkadot\nDocs MCP 、llms.txt 、SKILL.md、 Polkadot AI Chatbot\n一套AI resource，全面启用 MCP 集成，遵循新兴的 llms.txt 行业标准并提供分卷文档，并包含 Substrate MCP 及适用于智能合约开发的 Skill\nSui Network\nMCP 、** Ask Sui AI**\nNEAR Protocol\nllms.txt 、Docs MCP 、Agent Skills/Kit\n提供指向全文档的快链，专供 AI 编程助手使用，并为 Agent 开发提供了全栈组件（Near API JS、合约开发等技能）\nCosmos\nAsk AI\n由mintlify提供的AI机器人\nAptos\nAskAptos（聊天机器人） 、Agent Skills 、llms.txt\n在官方文档站显著位置内嵌 GPT 聊天机器人，并配合 Azure OpenAI 服务为开发者提供引导；同时全面发布 llms.txt\n4. CKB 在 AI 平台上的现有覆盖评估\n4.1 已有覆盖\ndeepwiki 平台\nimage2104×1730 236 KB\ncontext7 平台\nimage1916×2450 351 KB\n共同问题： 未及时同步代码到这两个平台，会导致 AI 拿到过时的信息。\n4.2 实测结果\n测试过程 ：分别在 bolt.new 和 replit.com 上使用相同的指令生成应用：\n编写一个 CKB 转账的 dApp 应用。\n二者的表现 ：\nbolt.new 一次性成功，交易可上链，并支持切换 testnet 与 mainnet，功能较完备\nReplit 未实现 testnet/mainnet 切换，首次发起交易时报 signer.client.addCellDepsOfKnownScripts is not a function 错误，将错误信息反馈给它后，它重新阅读 CCC 信息并修改代码，交易发送成功。\nimage1512×2852 358 KB\nDemo 链接（仅用于演示，请勿用它进行主网资产的交易） ：\nbolt.new: https://ckb-transfer-dapp-de-cffo.bolt.host/\nreplit: ckb-transfer-dapp–ckbfansdao.replit.app\n共同短板：两个平台对 MAX（最大可用金额）和 MIN（最小转账金额）的计算均出错——这类边界场景在现有 AI 训练数据和文档示例中覆盖不足。\n初步判断：AI 工具已经可以完成基础的 CKB 开发任务；但在涉及 CKB 特有概念（capacity 计算、cell 占用逻辑等）的高级场景下，AI 的知识明显不足，且难以自我纠正。\n4.3 缺口分析\n4.3.1 严重缺口（直接影响开发者体验）\n无 llms.txt / llms-full.txt ：docs.nervos.org 未提供 llms.txt，AI 工具无法高效获取官方文档。\n无项目规则文件模板 ：没有为 CKB 项目提供 .cursorrules / CLAUDE.md 等模板，开发者的 AI 助手缺少 CKB 特定上下文。\n无自定义 MCP 服务器 ：没有专门的 CKB MCP 服务器来提供 RPC 文档、Script 模板、错误码解释等结构化信息。\nScript 开发文档在 AI 平台上极度匮乏 ：ckb-std 仅 2 个代码片段，Rust/C Script 开发几乎无可供 AI 消费的结构化知识。\n参考示例不足 ：不仅需要提供正常情况下的代码示例，边界场景、高级用法的示例代码会显得尤为重要。\n4.3.2 中等缺口\n缺少 AI 友好的错误信息映射 ：CKB 的错误码与常见错误尚无结构化的解释文档可供 AI 检索。\n缺少端到端教程的 AI 友好版本 ：现有教程以 HTML 页面为主，而非 Markdown 或结构化格式。\n多语言 SDK 覆盖不均 ：Java SDK、Go SDK 等在 AI 平台上的覆盖较弱。\n4.3.3 轻度缺口\n社群问答未结构化 ：Discord/Telegram 中的高价值问答未被收集与结构化。\n缺少 CKB 特定的 AI 提示词工程指南 ：开发者不清楚如何更好地向 AI 描述 CKB 相关需求。\n4.4 对比总结：CKB vs Solana vs Ethereum\nAI First 维度\nSolana\nEthereum\nCKB\n官方 MCP 服务器\nmcp.solana.com（基金会维护）\n多个社区 MCP（ViemCP 等）\n无\nllms.txt\n文档站未确认\nwagmi/viem 全面支持\n无\nAI Coding Skills\n10+ 官方/社区 Skills\n多个 Skills，分门别类：ethskills.com 、github.com/austintgriffith/ethskills\n无\nAI 配置文件模板\n官方提供系统提示词示例\n社区分享 .cursorrules\n无\nContext7 代码片段\n丰富（多个 SDK）\n极丰富（viem 5800+）\n较少（CCC 141）\nAI 开发者指南\n官方文档站专页\n开发者页面设有 “Build onchain with agents” 专区：ethereum.org/developers/\n无\nAI Agent 生态\nSolana Agent Kit，12+ Agent\n专题页面策展：ethereum.org/ai-agents/\n无\nawesome-*-ai 策展\nawesome-solana-ai\n首页专区策展：ethereum.org/ai-agents/\n无\n基础设施商 AI 工具\nHelius 全家桶\nQuickNode MCP 等\n无\nClaude Code Plugin\nHelius 官方插件\n社区提供多个，例如 github.com/0xGval/evm-mcp-tools\n无\n4.5 从 Solana/Ethereum 等链的经验中 CKB 可借鉴的关键启示\n官方 MCP 服务器是基础中的基础 ：Solana 基金会亲自维护 mcp.solana.com，这是 AI First 战略的核心锚点。CKB 应将类似官方 MCP 服务器作为优先构建项。\nSkills/配置文件模板是成本效益比最高的投入 ：Solana 的 Skills 生态证明，精心编写的指令集能显著提升 AI 生成代码的准确性。CKB 应当立即着手创建等效的 .cursorrules / CLAUDE.md / SKILL.md 。\n通用标准达成共识，文档生产力彻底解放 ：越来越多的链开始兼容 MCP 协议，并发布自己的 llms.txt 。wagmi 在首页提示 “Are you an LLM?” 的做法值得借鉴，这让所有 AI 工具都能自动发现和消费文档。CKB 必须加速追赶这种基建潮流，否则我们精心撰写的文档在这些链面前就如同未被索引的孤岛，完全无法进入 AI 的“检索视野”。\n策展仓库建立生态认知 ：awesome-solana-ai 不仅是资源列表，更向开发者传递了“Solana 认真对待 AI 开发”的信号。CKB 可考虑在补齐相关AI toolkits 后建立类似的 awesome-ckb-ai 仓库。\n基础设施商协同是力量放大器 ：Helius 为 Solana 构建的 AI 工具链展示了基础设施商如何参与 AI First 生态。CKB 可鼓励生态伙伴构建类似工具。\n代码片段数量决定 AI 代码质量 ：viem 的 5800+ 代码片段 vs CCC 的 141 个，直接决定了 AI 生成代码的准确性与多样性。CKB 需要大幅增加文档中可运行的代码示例。\n“Ask AI”成为顶级生态的通用语言 ：BNB Chain、Polkadot、Aptos 和 Near 都在官网或 IDE 中内建了“Ask AI”或“Docs”助手。这意味着开发者遇到问题时，无需在不同的 Google 标签页间大海捞针，直接在开发者体验闭环内就能找到答案。对 CKB 而言，这极大地降低了新开发者的入门门槛。\n这些发现进一步印证：CKB 必须快速补齐我们在文档 AI 友好度和“开发者即时问答”等体验上的短板。接下来将在下一章节列出详细的行动建议。\n5. 改进建议与行动计划\n5.1 【P0】确保所有关键仓库已提交至 DeepWiki 与 Context7\n目标 ：让所有 AI 工具能高效、准确地获取到CKB相关的知识。\n具体行动 ：\n提交：比对目前DeepWiki、Context7上已有的CKB仓库，查缺补漏\n更新：有的仓库虽然已上传到这两个平台，但信息已过时，需做更新处理。\nDeepWiki目前不支持github action的方式更新，智能人工手动处理；\nContext7上的仓库可以添加github action来实时更新\n预期效果 ：开发者在 AI 编程工具里配置上 DeepWiki 与 Context7 两个 MCP 之后，在开发过程中询问到 AI 关于 CKB 的问题，AI 可以通过查询 MCP 服务器拿到更准确的答案。\n5.2 【P0】为 docs.nervos.org 添加 llms.txt\n目标 ：让所有 AI 工具能高效、准确地获取 CKB 官方文档。\n具体行动 ：\n在 docs.nervos.org 根目录添加 llms.txt （结构化目录 + 关键链接）。\n添加 llms-full.txt （完整文档的 Markdown 版本）。\n内容应覆盖：\nCKB 核心概念（Cell 模型、Script、Transaction）。\n开发入门指南。\nSDK 使用指南（CCC / Rust SDK / Go SDK / Java SDK…）。\nRPC 参考。\n常见错误与解决方案。\n部署指南。\n参考实现 ：\nVercel docs: https://vercel.com/docs/llms-full.txt\nAnthropic docs 使用 Mintlify 生成 llms.txt\ngithub 仓库提交到context7 之后，Context7 会自动生成llms.txt文档，可将其复制放入docs.nervos.org站点中。\n预期效果 ：所有 AI 编程工具在搜索 CKB 相关信息时，均可通过 llms.txt 快速获取最新、准确的官方文档，大幅减少幻觉。\n5.3 【P0】创建 AI 配置文件模板（.cursorrules / CLAUDE.md / SKILL.md）\n目标 ： 让使用任何 AI 工具的开发者在创建 CKB 项目时即获得 CKB 特定上下文\n具体行动 ：创建一套标准的 AI 配置文件模板，覆盖所有主流工具：：\nckb-project-template/\n├── .cursorrules # Cursor\n├── .windsurfrules # Windsurf\n├── .github/\n│ └── copilot-instructions.md # GitHub Copilot\n├── CLAUDE.md # Claude Code\n├── AGENTS.md # OpenAI Codex\n└── .cursor/\n└── rules/ # Cursor Rules (新版)\n配置文件核心内容应包括：CKB Cell 模型说明（强调与 EVM 的区别）、CCC SDK 推荐用法、Transaction 构建模式、常见错误及解决方案、重要参考链接等。\n分发渠道：内置到 create-ccc-app 模板和 offckb create 命令，在官方文档站提供下载，在 GitHub 仓库 README 中醒目引导。\n5.4 【P0】构建 CKB 专属 MCP 服务器\n目标 ：提供 CKB 生态的结构化、实时、可查询的文档服务，并使 AI Agent 能够查询 CKB 链上数据。\n现状 ：\n目前由 @jm9k 牵头实施的项目：github.com/sonami-tech/ckb-mcp。\n使用 Rust 编写，master 分支（主分支）最近一次更新在 8 个月前，develop 分支最近一次更新在两个月前。\nREADME 推荐搭配 Claude 使用，但使用 Windsurf 实测时发现兼容性不佳，会报授权错误：\nimage1920×1026 317 KB\n具体行动 ：\n大而全路线 ：基于 @modelcontextprotocol/sdk （TypeScript）构建 CKB MCP 服务器，内容方面参考 Jordan 的 ckb-mcp 项目实现，使用 TypeScript 语言可以降低贡献者的门槛。优点：开发者仅需安装一个 MCP；难点：MCP 开发人员需具备多面手能力，或需多团队协同。\n小而专路线 ：针对特定领域创建专门的 MCP，如 docs、rpc、ccc、script 等。优点：MCP server 职责明确，可由特定团队/人员负责编写与维护；缺点：对开发者不够友好，需安装多个 MCP 服务。\n技术实现参考 ：\n基于 @modelcontextprotocol/sdk 构建 TypeScript MCP 服务器。\n后端使用 RAG 管道，向量化所有 CKB 文档。\n部署为公共服务，开发者只需在 IDE 配置中添加 MCP 服务器地址即可。\n参考案例 ：\nsolana-mcp-official\nbnbchain-mcp\n5.5 【P1】增强 Script 开发在 AI 平台上的覆盖\n目标 ：让 AI 能准确指导 CKB Script（智能合约）开发。\n具体行动 ：\n充实 ckb-std 文档 ：当前在 Context7 上仅有 2 个代码片段，需大幅扩充：\n常用 syscall 使用示例（load_cell_data、load_script 等）。\n完整的 Script 开发从零到部署教程。\n常见 Script 模式（lock script / type script / 多签等）。\n创建 Script 示例仓库 ：专门存放各类 Script 示例，提交至 DeepWiki 与 Context7。\n提升 ckb-std 的 README 与文档质量 ：AI 平台会从 GitHub 仓库的 README、docs 目录、代码注释中提取信息，需确保这些内容丰富且结构化。\n5.6 【P1】优化现有仓库的 AI 可消费性\n目标 ：让 DeepWiki 和 Context7 能提取更多、更高质量的信息。\n具体行动 ：\n增强 README 文档 ：\n每个仓库的 README 应包含“Quick Start”章节，提供可复制粘贴的代码示例。\n添加常见用例的代码片段。\n确保所有公共 API 均配有文档注释。\n增加代码示例文件 ：\n在仓库中创建 /examples 或 /docs/examples 目录。\n每个示例都应独立可运行。\n覆盖最常见的开发场景。\n规范化代码注释 ：\n使用 JSDoc/TSDoc（TypeScript）或 rustdoc（Rust）格式。\n确保所有公共方法均包含参数说明与返回值说明。\nAI 平台会从代码注释中提取 API 用法信息。\n确保重要仓库均已提交 DeepWiki 和 Context7\n提升 Context7 上的每个Library的benchmark分数\nbenchmark 分数越高，AI获取到的内容越准确\n5.7 【P1】创建 awesome-ckb-ai 策展仓库（参考 awesome-solana-ai）\n目标 ：建立 CKB AI 开发者生态的统一入口，向开发者传达 CKB 认真对待 AI First 战略的信号。\n具体行动 ：\n在 GitHub 上创建 ckb-devrel/awesome-ckb-ai 仓库。\n分类收录：\nAI Coding Skills ：CKB 开发的 .cursorrules / CLAUDE.md / SKILL.md。\nMCP Servers ：CKB 官方 MCP + 社区 MCP。\nDeveloper Tools ：AI 增强的 CKB 开发工具。\nLearning Resources ：AI 友好的教程与文档。\nAI Agents ：基于 CKB 的 AI Agent 项目。\n设立社区贡献机制，鼓励生态开发者提交 PR。\n参考 ：awesome-solana-ai\n注 ：此项虽重要，但考虑到目前 CKB 上 AI 相关资源尚少，建议待资源丰富一些后再行实施。\n5.8 【P2】建立 AI 友好的错误信息知识库\n目标 ：当开发者遇到 CKB 错误并向 AI 求助时，AI 能给出准确的诊断与解决方案。\n具体行动 ：\n收集 CKB 开发中最常见的 50+ 条错误信息。\n为每条错误创建结构化文档（错误码 → 原因 → 解决方案 → 代码示例）。\n格式化为 Markdown，便于 AI 消费。\n集成至 MCP 服务器的 explain-error-code 工具中。\n同步至 docs.nervos.org 的 llms.txt 中。\n示例格式 ：\n## Error: TransactionFailedToVerify - ValidationFailure(-31)\n**含义**: Script 验证失败，group index 指向的 Script 执行返回非零退出码。\n**常见原因**:\n1. Lock Script 签名验证失败 — 使用了错误的私钥或地址。\n2. Type Script 逻辑错误 — 自定义 type script 的业务逻辑未满足。\n3. 容量不足 — 输出 Cell 的 capacity 不足以覆盖其占用空间。\n**调试步骤**:\n1. 使用 `ckb-debugger` 本地运行 Script 进行调试。\n2. 检查 `tx.witnesses` 是否已正确设置。\n3. 确认所有输入 Cell 的 lock script 对应的签名均已提供。\n**代码修复示例**:\n...\n5.9 【P2】创建 AI 友好的端到端教程\n目标 ：提供完整的、AI 可消费的教程内容。\n具体行动 ：\n将现有教程转换为 Markdown 格式，存放于专门的 GitHub 仓库中。\n教程应覆盖：\nCKB 基础：创建钱包、CKB 转账。\n进阶：部署 Script、创建 UDT、使用 Spore Protocol。\n集成：连接各类钱包（MetaMask/JoyID/UniSat 等）。\n高级：DAO 操作、跨链桥接。\n每个教程均应提供可直接运行的完整代码。\n提交至 DeepWiki 与 Context7。\n参考示例：dob-cookbook\n5.10 【P2】结构化社群 FAQ\n目标 ：将 Discord/Telegram 中反复出现的问题转化为 AI 可检索的知识。\n具体行动 ：\n定期从社区中收集高频问题。\n创建结构化 FAQ 文档（GitHub 仓库）。\n格式化为 Q&A 对，便于 AI RAG 检索。\n可考虑借助 AI 自动从社群消息中提取与归类问题。\n5.11 【P2】创建 CKB AI 开发者指南（参考 Solana 官方 AI 指南）\n目标 ：教会开发者如何更好地利用 AI 进行 CKB 开发。\n具体行动 ：\n撰写“如何用 AI 高效开发 CKB 应用”指南。\n内容包括：\n推荐的 AI 工具配置（如何配置 Context7 MCP、DeepWiki MCP）。\n如何写好 CKB 相关的 AI 提示词。\nCKB 项目的 AI 配置文件模板使用指南。\n常见 AI 幻觉陷阱及如何避免。\n6. 实施路线图\n6.1 Phase 1 — 低成本高收益（追平基线）\n#\n行动项\n参考对标\n预期影响\n1\n确保所有关键仓库已提交至 DeepWiki 与 Context7\n—\n2\n为 docs.nervos.org 添加 llms.txt / llms-full.txt\nwagmi.sh / viem.sh\n3\n创建 AI 配置文件模板（.cursorrules / CLAUDE.md / SKILL.md）\nSolana Skills 生态\n4\n创建 awesome-ckb-ai 策展仓库\nawesome-solana-ai\n目前 AI 相关资源有限（可先收集素材后期进行）\n6.2 Phase 2 — 内容增强（缩小差距）\n#\n行动项\n参考对标\n预期影响\n5\n充实重要仓库文档与示例\nviem 5800+ 片段\n6\n优化各仓库 README 与代码注释\nviem/wagmi 文档质量\n7\n创建错误信息知识库\nPhase 3（1–2 月）— 基础设施建设（建立竞争力）\n#\n行动项\n参考对标\n预期影响\n8\n构建 CKB 官方 MCP 服务器（mcp.ckb.dev）\nmcp.solana.com\n9\n创建 AI 友好的端到端教程\nSolana AI 开发指南\n10\n编写 CKB AI 开发者指南\nsolana.com/developers/guides/getstarted/intro-to-ai\n11\n结构化开发者社区 FAQ\nPhase 4（持续）— 生态维护与扩展\n#\n行动项\n参考对标\n预期影响\n12\n定期更新所有 AI 平台上的内容\n—\n13\n监控 AI 工具对 CKB 信息的回答质量\n—\n14\n鼓励生态伙伴构建 AI 工具（类似 Helius 之于 Solana）\nHelius AI 全家桶\n15\n探索 CKB Agent Kit（连接 AI Agent 到 CKB 协议）\nSolana Agent Kit\n写在最后\n这份报告的逻辑起点其实很朴素： AI 已悄然成为开发者与陌生技术之间最重要的那层中介。如果 AI 不理解 CKB，开发者也就很难顺畅地上手 CKB。\n好在，这是一个可以被系统性解决的问题。Solana 在一年多前面临着几乎一样的处境，他们通过官方 MCP、Skills 生态和 llms.txt 等一系列投入，明显改善了 AI 对 Solana 的理解质量。CKB 完全可以走同样的路径，而且起点并不低——DeepWiki 和 Context7 的基础覆盖已经到位，bolt.new 上的实测也验证了基础场景已能跑通。\nPhase 1 的三件事（补全仓库索引、AI 配置文件模板、llms.txt）的工作量预计不到两周，但能让每一个用 Cursor 或 Claude Code 开发 CKB 的人立即受益。这里是一个很不错的开始。\n值得一提的是，这份调研报告本身就是与 AI 协同完成的：我们让 Gemini Pro 和 Claude Sonnet 两个模型交叉验证了 CKB 在 AI 编程方面的缺口与行动计划，因为 AI 天然更清楚自己还“缺什么”。在整个过程中，@Hanssen 和 @RetricSu 以及几位来自 DevRel 团队的小伙伴为报告提供了不可或缺的校准与反馈，在此深表感谢。\n最后，想邀请你一起参与两件事：\n如果你正在用 AI 开发 CKB 应用 ，欢迎在评论区分享你遇到的 AI 幻觉案例——那些 AI 一本正经地胡说八道的真实瞬间。每一个例子都会直接帮助我们把 CKB 的 AI 开发体验打磨得更准确。\n如果你发现报告中还有遗漏的 AI 相关实践或方向 ，也欢迎在评论区留言斧正，我们会持续跟踪迭代。\n感谢每一位读到这里的你。\n附录\nA. Solana AI First 生态关键链接\n资源\n链接\nSolana Developer MCP（官方）\nhttps://mcp.solana.com/\nsolana-mcp-official (GitHub)\nGitHub - solana-foundation/solana-mcp-official · GitHub\nawesome-solana-ai\nGitHub - solana-foundation/awesome-solana-ai: Public repo of AI tooling to help build on Solana · GitHub\nsolana-dev-skill\nGitHub - solana-foundation/solana-dev-skill: Skills for agentic development on Solana (March 2026 best practices) · GitHub\nSolana AI 开发入门指南\nhttps://solana.com/developers/guides/getstarted/intro-to-ai\nHelius AI 工具\nHow to Use AI to Build Solana Apps (2026)\nHelius MCP Server\nHelius MCP Server - Helius Docs\nSolana Agent Kit (SendAI)\nGitHub - sendaifun/solana-agent-kit: connect any ai agents to solana protocols · GitHub\nB. Ethereum AI First 生态部分链接\n资源\n链接\nwagmi llms.txt\nhttps://wagmi.sh/llms.txt\nwagmi llms-full.txt\nhttps://wagmi.sh/llms-full.txt\nviem 文档\nhttps://viem.sh/\nevm-mcp-server\nGitHub - mcpdotdirect/evm-mcp-server: MCP server that provides LLMs with tools for interacting with EVM networks · GitHub\nRemix IDE AI Tools\nAI Tools — Remix - Ethereum IDE 1 documentation\nETH Skills\nhttps://ethskills.com/\nEthereum “Build onchain with agents”\nEthereum Developer Resources\nEthereum AI Agents 策展\nAI agents | AI agents on Ethereum | ethereum.org\nC. 参考资料\n2025 Stack Overflow Developer Survey\nBest AI Coding Agents: 9 Tools Compared\nCursor vs GitHub Copilot Deep Comparison\nAI Coding Config Files Compared\nWhy MCP Servers Are Essential for Documentation Sites\nWhat is llms.txt? Breaking Down the Skepticism\nContext7 MCP Server Guide\nHow to Use AI to Build Solana Apps (Helius)\nawesome-solana-ai (Solana Foundation)\nSolana Developer MCP", "content_html": "摘要： AI 辅助编程现已成为软件开发的主流，84% 的开发者已将 AI 工具融入工作流。本报告系统性地审视了这一趋势下 CKB 生态在 AI 覆盖上的现状与差距——从开发者工具选择、AI 检索机制、到 Solana/Ethereum 的 AI First 最佳实践对标分析。核心发现包括：CKB 在 AI 可消费性上存在严重缺口（无 llms.txt、无官方 MCP、无 Skills等），Context7 代码片段量仅为竞品链 SDK 的 1/22–1/41；同时 Bolt.new 上的实测也表明，AI 工具已具备基础 CKB 编程能力，但在高级场景中仍会出现幻觉或功能性错误 。这不是一个可行性问题，而是一个准确性和丰富度的问题。结合以上信息最终给出我们认为最有价值的改进建议。
\n以下是完整报告。
\n开发者使用的 AI 编程工具可归为四大类：
\n| 类型 | \n代表工具 | \n特点 | \n市场地位 | \n
|---|---|---|---|
| AI 原生 IDE | \nCursor, Windsurf, Google Antigravity 等 | \n从零构建，AI 作为核心交互层；全项目上下文感知；深度 Agent 能力 | \n增长最快，Cursor 估值约 $50B | \n
| IDE 插件/扩展 | \nGitHub Copilot, Cline, Augment Code, Amazon Q | \n集成到现有编辑器（VS Code / JetBrains）；尽可能延续开发者现有工作流 | \n用户量最大，Copilot 用户超 2000 万 | \n
| 终端/CLI Agent | \nClaude Code, Aider | \n命令行操作，无 GUI；自主性最强；适合复杂架构任务 | \n技术深度型开发者偏好 | \n
| Web 平台 | \nBolt.new, Replit | \n浏览器内运行，无需本地环境；适合快速原型和非开发者 | \n入门级 / 原型场景 | \n
CKB 的目标开发者群体（Web3 原生 + Web2 转型）在使用 AI 工具时呈现出不同的特点：
\n当开发者向 AI 提问时（如\"如何在 CKB 上创建一个转账交易？\"），AI 按以下优先级检索信息：
\n第 1 层：项目本地上下文（最高优先级）\n ├── 项目配置文件（CLAUDE.md / .cursorrules / AGENTS.md 等）\n ├── 当前打开的文件 & 最近编辑的文件\n ├── 项目依赖（package.json / Cargo.toml 等）\n └── 全代码库向量索引（语义搜索）\n ↓\n第 2 层：MCP 服务器（外部结构化数据源）\n ├── Context7 MCP — 9000+ 库的实时文档检索\n ├── DeepWiki MCP — GitHub 仓库的 AI 文档\n └── 自定义 MCP 服务器\n ↓\n第 3 层：AI 模型训练数据（内置知识）\n ├── 公开文档、教程、Stack Overflow 等\n └── GitHub 公开仓库代码\n ↓\n第 4 层：Web 搜索（实时补充）\n ├── 搜索引擎结果\n └── llms.txt / llms-full.txt 文件\n第 1 层：项目本地上下文
\nAI 编程助手会首先索引开发者的整个项目：
| 配置文件 | \n适用工具 | \n格式 | \n
|---|---|---|
CLAUDE.md | \nClaude Code | \nMarkdown，支持 5 层继承 | \n
.cursorrules | \nCursor | \n纯文本/Markdown | \n
copilot-instructions.md | \nGitHub Copilot | \nMarkdown | \n
.windsurfrules | \nWindsurf | \n纯文本/Markdown | \n
AGENTS.md | \nOpenAI Codex/ChatGPT | \nMarkdown | \n
第 2 层：MCP 服务器
\nMCP 的工作流程如下：
\nContext7 的工作方式 ：
\nresolve-library-id 和 get-library-docs 两个工具向 AI 客户端暴露数据。DeepWiki 的工作方式 ：
\nread_wiki_structure 、read_wiki_contents 、ask_question 等工具。第 3 层：训练数据
\nAI 模型的训练数据有时效性问题。对于 CKB 这样的小众链，训练数据中的 CKB 信息量远少于 Ethereum/Solana。这使得第 1、2 层的信息供给尤为关键——如果这两层没有足够准确的信息，AI 就会用训练数据里有限且可能过时的知识来\"推断\"答案。
\nllms.txt 是一个新兴标准（类似 robots.txt），以 Markdown 格式提供网站内容的结构化摘要。llms-full.txt 则包含完整内容，供 AI 模型直接消费。开发者提问：\"如何用 CCC 在 CKB 上创建一个 UDT 转账？\"\n ↓\n[1] 分析意图：识别关键词 CCC / CKB / UDT / 转账\n ↓\n[2] 搜索本地上下文：检查项目依赖与现有代码\n ↓\n[3] 查询 MCP 服务器：Context7 获取 CCC 文档 / DeepWiki 获取仓库架构\n ↓\n[4] 补充训练数据中的 CKB 知识\n ↓\n[5] 信息仍不足 → 触发 Web 搜索\n ↓\n[6] 综合上下文，生成代码答案\n ↓\n[7] 验证与迭代：自动运行 / 检查错误 / 修复\n关键痛点 ：如果在第 2–4 层都找不到足够准确的 CKB 信息，AI 极易产生“幻觉”——生成看似合理但实际错误的代码，这将严重损害开发者对工具的信任和开发效率。
\nSolana 和 Ethereum 是目前在 AI First 开发者体验方面投入最大、成效最显著的两条链。
\nSolana 基金会已将 AI 辅助开发确立为一等战略 ，构建了业内最为完整的 AI 开发者工具链。
\nSolana 基金会维护的官方 MCP 服务器，可直接集成到 Cursor、Windsurf、Claude Code 等 AI IDE 中：
\nmcp.solana.com/mcp，开发者仅需一行配置即可使用。Solana 提出了 “Skills”模式 ——一套精心编写的指令集，旨在教会 AI 如何成为 Solana 专家开发者。这是极具创新性的做法：
\n| Skill 名称 | \n维护方 | \n覆盖领域 | \n
|---|---|---|
solana-dev-skill | \nSolana Foundation | \n端到端 Solana 开发：钱包连接、Anchor 程序、测试、安全 | \n
helius-phantom-skill | \nHelius Labs | \n前端 dApp 开发：React/RN + Phantom Connect SDK | \n
metaplex-skill | \nMetaplex Foundation | \nNFT 开发：Core NFTs、Candy Machine、Umi/Kit SDK | \n
solana-anchor-claude-skill | \nQuickNode Labs | \nAnchor 合约开发 + 测试（LiteSVM） | \n
solana-game-skill | \n社区 | \n游戏开发：C#、React Native、Unity SDK | \n
solana-skills-plugin | \n社区 | \n安全审计 + ZK Compression + 漏洞检测 | \n
pinocchio-skill | \nSendAI | \n高性能 Solana 程序（可减少 88-95% 计算单元） | \n
vulnhunter-skill | \nSendAI | \n安全漏洞检测与变体分析 | \n
Skills 的关键特点 ：
\nHelius 作为 Solana 的基础设施商，构建了完整的 AI 开发者工具套件：
\n| 工具 | \n功能 | \n规模 | \n
|---|---|---|
| Helius MCP Server | \n结构化 API 调用（getBalance、parseTransaction 等） | \n60+ 工具 | \n
| Helius Skills | \n专家指令集（Build / DFlow / Phantom / SVM） | \n4 大领域 | \n
| Helius CLI | \n命令行工具，支持 --json 输出 | \n95+ 命令 | \n
| Claude Code Plugin | \n一键安装，集成 MCP + Skills + 参考文件 | \n全家桶 | \n
安装仅需一行命令：
\nclaude mcp add helius npx helius-mcp@latest\nSolana Foundation 维护的 awesome-solana-ai 仓库，系统性收录了：
\nSolana 官方文档站（solana.com）设有专门 AI 开发入门指南，涵盖：
\nEthereum 虽未像 Solana 那样由基金会统一推动 AI First 战略，但凭借庞大的生态和社区，其 AI 可消费性已相当成熟。
\nEthereum 核心库已全面采用 llms.txt 标准：
| 项目 | \nllms.txt | \nllms-full.txt | \n
|---|---|---|
| wagmi.sh | \n![\":white_check_mark:\"](\"https://talk.nervos.org/images/emoji/apple/white_check_mark.png?v=15\" "\\":white_check_mark:\\"") /llms.txt | \n /llms-full.txt | \n
| viem.sh | \n /llms.txt | \n /llms-full.txt | \n
wagmi 在首页醒目位置展示了 AI 友好标识：\"Are you an LLM? View /llms.txt for optimized Markdown documentation, or /llms-full.txt for full documentation bundle \"。
\n
以 viem（Ethereum TypeScript 接口库，在 CKB 生态中可与 CCC 类比）为例：
\n| 指标 | \nviem (Ethereum) | \nCCC (CKB) | \n差距倍数 | \n
|---|---|---|---|
| Context7 代码片段数 | \n3,090 - 5,827 | \n141 | \n22x - 41x | \n
| 基准分 | \n90.35 | \n85.1 | \n1.06x | \n
| 来源信誉 | \nHigh | \nMedium | \n— | \n
| llms.txt 独立索引 | \n（单独条目） | \n![\":cross_mark:\"](\"https://talk.nervos.org/images/emoji/apple/cross_mark.png?v=15\" "\\":cross_mark:\\"") | \n— | \n
viem 在 Context7 上拥有多个索引条目（GitHub 仓库 + llms-full.txt + 文档站），总代码片段数超过 10,000 ，而 CCC 仅有 141 个。这意味着 AI 在生成 Ethereum 代码时拥有 70 倍以上 的参考素材。
\nEthereum 生态已有多个专属 MCP 服务器：
\nEthereum 社区在 GitHub 上已有大量 Solidity/.cursorrules 模板流传，覆盖：
\nEthereum 在生态构建方面更进一步，其开发者门户（ethereum.org）已设有两个专门的策展页面：
\n
同时，社区还维护着 ETH Skills，这是一个专门为 AI Agent 提供实时以太坊开发文档的知识库，内容涵盖 Gas 成本、Solidity 模式、Layer 2、DeFi 组合性、安全、测试与生产部署等关键领域。
\n除了 Solana 和 Ethereum 的深度布局，越来越多的公链已直接将“Ask AI”或类似的文档查询助手内建至开发者门户。纵观它们的实践，将文档对内对外全面“打开”，已成为一种无需言明的新标配 。以下列举了其中一些链的主要动作：
\n| 链 | \n核心工具/功能 | \n亮点 / 当前状态 | \n
|---|---|---|
| BNB Chain | \nMCP、Ask AI MCP （IDE 内文档查询） | \n推出了以 MCP（模型上下文协议）为基础的专门服务。 | \n
| Polkadot | \nDocs MCP 、llms.txt 、SKILL.md、 Polkadot AI Chatbot | \n一套AI resource，全面启用 MCP 集成，遵循新兴的 llms.txt 行业标准并提供分卷文档，并包含 Substrate MCP 及适用于智能合约开发的 Skill | \n
| Sui Network | \nMCP 、** Ask Sui AI** | \n\n |
| NEAR Protocol | \nllms.txt 、Docs MCP 、Agent Skills/Kit | \n提供指向全文档的快链，专供 AI 编程助手使用，并为 Agent 开发提供了全栈组件（Near API JS、合约开发等技能） | \n
| Cosmos | \nAsk AI | \n由mintlify提供的AI机器人 | \n
| Aptos | \nAskAptos（聊天机器人） 、Agent Skills 、llms.txt | \n在官方文档站显著位置内嵌 GPT 聊天机器人，并配合 Azure OpenAI 服务为开发者提供引导；同时全面发布 llms.txt | \n
deepwiki 平台
\n
context7 平台
\n
共同问题： 未及时同步代码到这两个平台，会导致 AI 拿到过时的信息。
\n测试过程 ：分别在 bolt.new 和 replit.com 上使用相同的指令生成应用：
\n\n\n编写一个 CKB 转账的 dApp 应用。
\n
二者的表现 ：
\n![\":+1:\"](\"https://talk.nervos.org/images/emoji/apple/+1.png?v=15\" "\\":+1:\\"")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/b/b7e1ad908c0266e7e087bbf094740d783cebf59b.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/5/5458a1063d52be5c21d2c9fe5f3fb0d92b74322c.png\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/6/626266067e2c1a58697aac59e74ea30d64f010b6.png\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/b/b442b0b18d5472475cb042f0dff5ed2fbb6e55b6.jpeg\")
signer.client.addCellDepsOfKnownScripts is not a function 错误，将错误信息反馈给它后，它重新阅读 CCC 信息并修改代码，交易发送成功。Demo 链接（![\":warning:\"](\"https://talk.nervos.org/images/emoji/apple/warning.png?v=15\" "\\":warning:\\"")
仅用于演示，请勿用它进行主网资产的交易） ：
共同短板：两个平台对 MAX（最大可用金额）和 MIN（最小转账金额）的计算均出错——这类边界场景在现有 AI 训练数据和文档示例中覆盖不足。
\n初步判断：AI 工具已经可以完成基础的 CKB 开发任务；但在涉及 CKB 特有概念（capacity 计算、cell 占用逻辑等）的高级场景下，AI 的知识明显不足，且难以自我纠正。
\n![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/8/805dfab1a7fdb8e52a037886f837ba3fa4fac26d.jpeg\")
.cursorrules / CLAUDE.md 等模板，开发者的 AI 助手缺少 CKB 特定上下文。ckb-std 仅 2 个代码片段，Rust/C Script 开发几乎无可供 AI 消费的结构化知识。| AI First 维度 | \nSolana | \nEthereum | \nCKB | \n
|---|---|---|---|
| 官方 MCP 服务器 | \n mcp.solana.com（基金会维护） | \n 多个社区 MCP（ViemCP 等） | \n 无 | \n
| llms.txt | \n 文档站未确认 | \n wagmi/viem 全面支持 | \n 无 | \n
| AI Coding Skills | \n 10+ 官方/社区 Skills | \n 多个 Skills，分门别类：ethskills.com 、github.com/austintgriffith/ethskills | \n 无 | \n
| AI 配置文件模板 | \n 官方提供系统提示词示例 | \n 社区分享 .cursorrules | \n 无 | \n
| Context7 代码片段 | \n丰富（多个 SDK） | \n极丰富（viem 5800+） | \n较少（CCC 141） | \n
| AI 开发者指南 | \n 官方文档站专页 | \n 开发者页面设有 “Build onchain with agents” 专区：ethereum.org/developers/ | \n 无 | \n
| AI Agent 生态 | \n Solana Agent Kit，12+ Agent | \n 专题页面策展：ethereum.org/ai-agents/ | \n 无 | \n
| awesome-*-ai 策展 | \n awesome-solana-ai | \n 首页专区策展：ethereum.org/ai-agents/ | \n 无 | \n
| 基础设施商 AI 工具 | \n Helius 全家桶 | \n QuickNode MCP 等 | \n 无 | \n
| Claude Code Plugin | \n Helius 官方插件 | \n 社区提供多个，例如 github.com/0xGval/evm-mcp-tools | \n 无 | \n
.cursorrules / CLAUDE.md / SKILL.md 。llms.txt 。wagmi 在首页提示 “Are you an LLM?” 的做法值得借鉴，这让所有 AI 工具都能自动发现和消费文档。CKB 必须加速追赶这种基建潮流，否则我们精心撰写的文档在这些链面前就如同未被索引的孤岛，完全无法进入 AI 的“检索视野”。这些发现进一步印证：CKB 必须快速补齐我们在文档 AI 友好度和“开发者即时问答”等体验上的短板。接下来将在下一章节列出详细的行动建议。
\n目标 ：让所有 AI 工具能高效、准确地获取到CKB相关的知识。
\n具体行动 ：
\n预期效果 ：开发者在 AI 编程工具里配置上 DeepWiki 与 Context7 两个 MCP 之后，在开发过程中询问到 AI 关于 CKB 的问题，AI 可以通过查询 MCP 服务器拿到更准确的答案。
\n目标 ：让所有 AI 工具能高效、准确地获取 CKB 官方文档。
\n具体行动 ：
\ndocs.nervos.org 根目录添加 llms.txt （结构化目录 + 关键链接）。llms-full.txt （完整文档的 Markdown 版本）。参考实现 ：
\n预期效果 ：所有 AI 编程工具在搜索 CKB 相关信息时，均可通过 llms.txt 快速获取最新、准确的官方文档，大幅减少幻觉。
\n目标 ： 让使用任何 AI 工具的开发者在创建 CKB 项目时即获得 CKB 特定上下文
\n具体行动 ：创建一套标准的 AI 配置文件模板，覆盖所有主流工具：：
\nckb-project-template/\n├── .cursorrules # Cursor\n├── .windsurfrules # Windsurf\n├── .github/\n│ └── copilot-instructions.md # GitHub Copilot\n├── CLAUDE.md # Claude Code\n├── AGENTS.md # OpenAI Codex\n└── .cursor/\n └── rules/ # Cursor Rules (新版)\n配置文件核心内容应包括：CKB Cell 模型说明（强调与 EVM 的区别）、CCC SDK 推荐用法、Transaction 构建模式、常见错误及解决方案、重要参考链接等。
\n分发渠道：内置到 create-ccc-app 模板和 offckb create 命令，在官方文档站提供下载，在 GitHub 仓库 README 中醒目引导。
目标 ：提供 CKB 生态的结构化、实时、可查询的文档服务，并使 AI Agent 能够查询 CKB 链上数据。
\n现状 ：
\n具体行动 ：
\n![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/2/288bd815d83133f33dc292a86a9a6b35c9d68882.jpeg\")
@modelcontextprotocol/sdk （TypeScript）构建 CKB MCP 服务器，内容方面参考 Jordan 的 ckb-mcp 项目实现，使用 TypeScript 语言可以降低贡献者的门槛。优点：开发者仅需安装一个 MCP；难点：MCP 开发人员需具备多面手能力，或需多团队协同。技术实现参考 ：
\n@modelcontextprotocol/sdk 构建 TypeScript MCP 服务器。参考案例 ：
\n\n目标 ：让 AI 能准确指导 CKB Script（智能合约）开发。
\n具体行动 ：
\n目标 ：让 DeepWiki 和 Context7 能提取更多、更高质量的信息。
\n具体行动 ：
\n/examples 或 /docs/examples 目录。目标 ：建立 CKB AI 开发者生态的统一入口，向开发者传达 CKB 认真对待 AI First 战略的信号。
\n具体行动 ：
\nckb-devrel/awesome-ckb-ai 仓库。注 ：此项虽重要，但考虑到目前 CKB 上 AI 相关资源尚少，建议待资源丰富一些后再行实施。
\n目标 ：当开发者遇到 CKB 错误并向 AI 求助时，AI 能给出准确的诊断与解决方案。
\n具体行动 ：
\nexplain-error-code 工具中。示例格式 ：
\n## Error: TransactionFailedToVerify - ValidationFailure(-31)\n\n**含义**: Script 验证失败，group index 指向的 Script 执行返回非零退出码。\n\n**常见原因**:\n1. Lock Script 签名验证失败 — 使用了错误的私钥或地址。\n2. Type Script 逻辑错误 — 自定义 type script 的业务逻辑未满足。\n3. 容量不足 — 输出 Cell 的 capacity 不足以覆盖其占用空间。\n\n**调试步骤**:\n1. 使用 `ckb-debugger` 本地运行 Script 进行调试。\n2. 检查 `tx.witnesses` 是否已正确设置。\n3. 确认所有输入 Cell 的 lock script 对应的签名均已提供。\n\n**代码修复示例**:\n...\n目标 ：提供完整的、AI 可消费的教程内容。
\n具体行动 ：
\n参考示例：dob-cookbook
\n目标 ：将 Discord/Telegram 中反复出现的问题转化为 AI 可检索的知识。
\n具体行动 ：
\n目标 ：教会开发者如何更好地利用 AI 进行 CKB 开发。
\n具体行动 ：
\n| # | \n行动项 | \n参考对标 | \n预期影响 | \n
|---|---|---|---|
| 1 | \n确保所有关键仓库已提交至 DeepWiki 与 Context7 | \n— | \n![\":star:\"](\"https://talk.nervos.org/images/emoji/apple/star.png?v=15\" "\\":star:\\"") | \n
| 2 | \n为 docs.nervos.org 添加 llms.txt / llms-full.txt | \nwagmi.sh / viem.sh | \n | \n
| 3 | \n创建 AI 配置文件模板（.cursorrules / CLAUDE.md / SKILL.md） | \nSolana Skills 生态 | \n | \n
| 4 | \n创建 awesome-ckb-ai 策展仓库 | \nawesome-solana-ai | \n 目前 AI 相关资源有限（可先收集素材后期进行） | \n
| # | \n行动项 | \n参考对标 | \n预期影响 | \n
|---|---|---|---|
| 5 | \n充实重要仓库文档与示例 | \nviem 5800+ 片段 | \n | \n
| 6 | \n优化各仓库 README 与代码注释 | \nviem/wagmi 文档质量 | \n | \n
| 7 | \n创建错误信息知识库 | \n\n | | \n
| # | \n行动项 | \n参考对标 | \n预期影响 | \n
|---|---|---|---|
| 8 | \n构建 CKB 官方 MCP 服务器（mcp.ckb.dev） | \nmcp.solana.com | \n | \n
| 9 | \n创建 AI 友好的端到端教程 | \nSolana AI 开发指南 | \n | \n
| 10 | \n编写 CKB AI 开发者指南 | \nsolana.com/developers/guides/getstarted/intro-to-ai | \n | \n
| 11 | \n结构化开发者社区 FAQ | \n\n | | \n
| # | \n行动项 | \n参考对标 | \n预期影响 | \n
|---|---|---|---|
| 12 | \n定期更新所有 AI 平台上的内容 | \n— | \n | \n
| 13 | \n监控 AI 工具对 CKB 信息的回答质量 | \n— | \n | \n
| 14 | \n鼓励生态伙伴构建 AI 工具（类似 Helius 之于 Solana） | \nHelius AI 全家桶 | \n | \n
| 15 | \n探索 CKB Agent Kit（连接 AI Agent 到 CKB 协议） | \nSolana Agent Kit | \n | \n
这份报告的逻辑起点其实很朴素： AI 已悄然成为开发者与陌生技术之间最重要的那层中介。如果 AI 不理解 CKB，开发者也就很难顺畅地上手 CKB。
\n好在，这是一个可以被系统性解决的问题。Solana 在一年多前面临着几乎一样的处境，他们通过官方 MCP、Skills 生态和 llms.txt 等一系列投入，明显改善了 AI 对 Solana 的理解质量。CKB 完全可以走同样的路径，而且起点并不低——DeepWiki 和 Context7 的基础覆盖已经到位，bolt.new 上的实测也验证了基础场景已能跑通。
\nPhase 1 的三件事（补全仓库索引、AI 配置文件模板、llms.txt）的工作量预计不到两周，但能让每一个用 Cursor 或 Claude Code 开发 CKB 的人立即受益。这里是一个很不错的开始。
\n值得一提的是，这份调研报告本身就是与 AI 协同完成的：我们让 Gemini Pro 和 Claude Sonnet 两个模型交叉验证了 CKB 在 AI 编程方面的缺口与行动计划，因为 AI 天然更清楚自己还“缺什么”。在整个过程中，@Hanssen 和 @RetricSu 以及几位来自 DevRel 团队的小伙伴为报告提供了不可或缺的校准与反馈，在此深表感谢。
\n最后，想邀请你一起参与两件事：
\n感谢每一位读到这里的你。
\n| 资源 | \n链接 | \n
|---|---|
| Solana Developer MCP（官方） | \nhttps://mcp.solana.com/ | \n
| solana-mcp-official (GitHub) | \nGitHub - solana-foundation/solana-mcp-official · GitHub | \n
| awesome-solana-ai | \nGitHub - solana-foundation/awesome-solana-ai: Public repo of AI tooling to help build on Solana · GitHub | \n
| solana-dev-skill | \nGitHub - solana-foundation/solana-dev-skill: Skills for agentic development on Solana (March 2026 best practices) · GitHub | \n
| Solana AI 开发入门指南 | \nhttps://solana.com/developers/guides/getstarted/intro-to-ai | \n
| Helius AI 工具 | \nHow to Use AI to Build Solana Apps (2026) | \n
| Helius MCP Server | \nHelius MCP Server - Helius Docs | \n
| Solana Agent Kit (SendAI) | \nGitHub - sendaifun/solana-agent-kit: connect any ai agents to solana protocols · GitHub | \n
| 资源 | \n链接 | \n
|---|---|
| wagmi llms.txt | \nhttps://wagmi.sh/llms.txt | \n
| wagmi llms-full.txt | \nhttps://wagmi.sh/llms-full.txt | \n
| viem 文档 | \nhttps://viem.sh/ | \n
| evm-mcp-server | \nGitHub - mcpdotdirect/evm-mcp-server: MCP server that provides LLMs with tools for interacting with EVM networks · GitHub | \n
| Remix IDE AI Tools | \nAI Tools — Remix - Ethereum IDE 1 documentation | \n
| ETH Skills | \nhttps://ethskills.com/ | \n
| Ethereum “Build onchain with agents” | \nEthereum Developer Resources | \n
| Ethereum AI Agents 策展 | \nAI agents | AI agents on Ethereum | ethereum.org | \n
在进入主题之前，我觉得有必要先用较为通俗的语言描述一下 Fiber 当前的一些大多数用户可能会关心的功能设定：
\n每一个 Fiber 节点都是 “节点 + 钱包” 的组合体，节点模块有自己的身份 ID，钱包模块则提供 CKB 链上资产的操作权限。
\n让 Fiber 节点关联 CKB 钱包有两种方式，一种是你直接提供私钥文件并设置一个解锁密码，以后都要提供正确的密码才能启动节点，这是内置钱包模式；另一种是节点发你 CKB 交易，你自己拿去签名，然后将签名信息发回节点即可，这是外置钱包模式。
\n要自己在机器上运行 Fiber 节点，要么下载 Fiber 的源代码来编译可执行程序，要么直接下载已经编译好的可执行程序。
\nFiber 团队还提供了 Fiber 的 Wasm 版本，也就是可以直接在浏览器里运行 Fiber 节点，这是目前能让非技术用户直接运行 Fiber 节点的最佳方式，但由于技术原因，这个版本砍掉了部分功能。
\n在 Fiber 里你无法像 CKB 网络那样直接向某个地址转账，流程是需要目标节点先成一个收款 “发票”，然后你通过向这个发票付款来完成转账，也就是对方不想收款，那你就没法向他付款，并且交易双方的节点都要求同时在线并互相可感知。
\nFiber 团队提供了 fiber-cli，支持像 ckb-cli 那样通过终端或命令行来与 Fiber 节点交互。
Fiber 目前还在持续开发当中，上述提到的技术细节都有可能在未来的版本迭代中发生改变，但大部分都集中在技术细节优化和提供新功能上，对基础的技术框架一般不会做太大改动。
\nFiber 的技术优势主要体现在 “高频交易” 场景中，尤其是小额且高频的，对于大额或低频的交互场景，其优势就很难发挥出来。
\n\n\n什么是 fiber-js
\n
https://www.npmjs.com/package/@nervosnetwork/fiber-js
\n一个封装了 Fiber Wasm 版本的 TypeScript 开发包，将 Rust 版本的 Fiber 删减一些功能后编译到 Wasm 二进制，再通过一些基本的封装工作将其封装起来并提供一个简单好用的编程接口。
\n我们可以通过 fiber-js 直接在浏览器里运行一个阉割版的 Fiber 节点，由于 Fiber 现已支持外置钱包模式，所以可以不用传入你的钱包私钥，直接使用常用的 CKB 钱包，比如 JoyID、UTXOGlobal 等。
当前版本（v0.8.1）的 fiber-js 受限于浏览器运行环境，有以下几个特点：
没有 RPC 服务，毕竟浏览器里也没法运行服务器
\n没有 RocksDB 数据库，直接使用浏览器中内置的 IndexedDB 服务
\n没有 WatchTower 服务，无法实时侦测异常操作
\n只能通过 443/WSS 协议连接 Rust 版本的 Fiber 节点，WASM 版本的 Fiber 节点无法被主动连接
\n\n\nfiber-js 的应用场景
\n
受限于浏览器运行环境的限制，集成了 fiber-js 的 Web3 应用程序无法针对 P2P 场景进行业务构建，例如 P2P 对战、P2P 聊天、P2P 支付等，但 CS 场景是没问题的，即基于 Client 与 Server 的业务模式，比如按流量扣费的在线视频平台、按 Token 计费的 AI Agent 服务等。
Fiber 为了自身网络信息传输的稳定性与有效性，会尽可能的期望节点是常驻运行的，而这一点 fiber-js 所涉及的应用场景都是很难做到的，因为很难想象一个网页会长时间打开且不关闭的情况，所以目前可以这么理解：
Rust 版本的 Fiber 同时针对 Client + Server 应用场景，但缺点是需要显式的运行一个 Fiber 节点
\nWasm 版本的 Fiber 只针对 Client 应用场景，但优点是支持直接在浏览器里隐式的运行一个 Fiber 节点，让普通用户对 Fiber 节点的存在无感
\n\n\n基于 fiber-js 的 demo
\n
该 Demo 是直接集成在 CCC 里的，用于全面的展示 fiber-js 所提供的大部分功能，包括连接节点、创建通道、生成发票和发送支付等，直接使用该 demo 来测试 Fiber 的相关操作流程，不过受限于 fiber-js 的限制，无法体验完全版的 Fiber 功能。
Demo 功能简介：
\n节点配置：将 Fiber 配置文件内容整个复制到文本框中
\n\n生成 Fiber Key：通过签名一个自定义字符串来生成 Fiber 的节点身份信息
\n\n运行 Fiber 节点：使用外置钱包模式启动 Fiber 服务，可查看操作日志
\n\n\n建立 Channel 连接：与直连的一个 Peer 建立 Channel
\n\n生成 Invoice 与支付：在通道内生成 Invoice 并完成支付
\n\n\n注：此 Demo 会跟着 CCC 的版本更新来发布
\n我在开发 Demo 的过程中，积累了一些使用 Fiber 的经验和感受，Fiber 是一个很有潜力的项目，并且仍在紧锣密鼓的开发当中，我希望就我观察到的一些问题进行探讨，起到抛砖引玉的效果。
\n\n\nFiber 的官网设计还是以面向开发者群体为主，忽略了非技术群体的感受
\n
官网上充斥着大量的技术性说明与介绍，生态项目板块指向也都是项目的 Github 地址，而不是项目的使用入口或者演示视频，非技术群体用户无法直接通过官网建立对 Fiber 生态的感性认知，我觉得这一点是有待斟酌的。
\n当前的设计固然有它的道理：尽可能的服务开发者，期望降低开发者在 Fiber 生态中开发应用的门槛。但这样的设计忽略了一个重要的现实情况，那就是应用开发出来后并没有为它们设置向普通非技术用户展示的途径，开发出来的 Fiber 应用很可能就此石沉大海，无法触及普通用户，也就无法对开发者形成正向激励。
\n降低开发门槛就好像售前服务，开发完成后帮助向用户展示就好像售后服务，两者缺一不可，我们目前的主要精力都放在了售前服务上，却忽略了售后服务的重要性。
\n\n\n运行 Fiber 节点的门槛较高
\n
几乎所有的 Fiber 应用都会要求用户在本地启动一个 Fiber 节点，但让非技术群体用户自己从 Github 上下载 Fiber 二进制文件并在命令行终端里进行配置和启动节点是一件门槛极高的操作。
\n其实如果能提供一个桌面端 Fiber 节点应用并集成钱包功能，就像 Neuron 那样，打开就能直接启动节点，在应用里调整节点配置和调用 RPC 接口等，将极大的降低非技术类用户启动 Fiber 节点的门槛，如果有这样的桌面应用存在，那就可以直接参考传统区块链钱包的做法，集成一个 Fiber 应用市场，打造成 Fiber 生态的入口。
\n\n\n\n
fiber-js的潜力还有更多可挖的空间
fiber-js 运行着一个阉割版的 Fiber 节点，但其在浏览器中运行的特点，即带来了方便但也受限于不少技术问题，如果能够尽可能解决大部分技术问题，我相信 Wasm 版本的 Fiber 对开发者将更有吸引力。
官方文档中缺少对 fiber-js 的相关介绍和引导，可能会导致一些开发者都不知道其存在的问题。
Status: RFC — early design discussion
\nScope: Source package registry, deployment registry, lockfile binding, and
\nbuilder verification for CellScript on CKB
\nTarget Version: 0.19 ~ 0.20
\n\nCellScript packages should be distributed like development packages, but
\n
\nverified like smart-contract deployments.
The off-chain registry optimizes for source distribution and developer
\nexperience. CKB records only compact, verifiable deployment truth where it is
\nactually useful. The lockfile binds the two.
CellScript packages exist in three identity layers, each with a distinct
\nverification scope:
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/8/8f77ff2beee3f0ab9c8868a707fd5046fe4917d5.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/8/8cd76cc05f72af95e6c728d1fae327329c669895.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/4/420b398868a1c5cc2711eae96c6f0302c6e010e3.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/2/2cce0903c61bc26ffe3a2a254dd683dee0699a59.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/b/b4379cf0801ac12d39fe012a232ef0b4546dba03.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/8/84116e4552648574aa29914a076b86bc663d991c.jpeg\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/2/29671d7795747f3b4bd29d869f30f723f279e297.png\")
┌─────────────────────────────────────────────────────────────┐\n│ Package Identity │\n│ namespace / name / version / source_hash │\n│ Carrier: Cell.toml + source registry index │\n│ Verified: compile time │\n├─────────────────────────────────────────────────────────────┤\n│ Build Identity │\n│ compiler_version / metadata_schema / schema_hash / │\n│ abi_hash / artifact_hash / constraints_hash │\n│ Carrier: Cell.lock [package.build] │\n│ Verified: build time │\n├─────────────────────────────────────────────────────────────┤\n│ Deployment Identity │\n│ chain / network / code_cell / out_point / data_hash / │\n│ dep_type / type_id_lineage / script_role │\n│ Carrier: Deployed.toml │\n│ Verified: runtime / production │\n└─────────────────────────────────────────────────────────────┘\nEach layer is independently meaningful but cryptographically bound to the
\nlayers above and below through the lockfile.
A CellScript package can exist in at least two operational states:
\nSource-only / undeployed package. A normal development package containing
\n.cell source files, interfaces, schemas, docs, tests, examples, and
\nreproducible build metadata. It can be imported, compiled, tested, audited, and
\nused as a library dependency. However, it does not by itself claim any
\nproduction deployment identity on CKB.
Deployment-bound package. A package version whose built artifact has been
\ndeployed, and whose deployment identity can be verified. For CKB, this means
\nbinding the package version to facts such as CellDep, OutPoint, data_hash,
\ndep_type, script/code hash, schema/ABI commitments, constraints report,
\ncompiler version, and possibly type-id lineage.
A deployment-bound package is what wallets and production builders should rely
\non when constructing real transactions.
The same source package version may have zero, one, or many deployment
\nbindings. For example, amm@1.2.0 may start as a source-only package, later
\ngain a CKB testnet deployment, then eventually a CKB mainnet deployment. These
\nare separate deployment records attached to the same source/package identity,
\nnot separate source packages.
amm@1.2.0\n ├─ source: blake2b:0xabcd...\n ├─ build: artifact=0x1234... abi=0xdef0...\n ├─ deployed:\n │ ├─ aggron4: out_point=0xaaaa...:0 status=active\n │ └─ mainnet: status=candidate\n └─ (same source version, multiple deployment bindings)\nIt is unlikely that publishing every CellScript source package directly to CKB
\nis the right default.
Source archives, docs, examples, tests, schema manifests, and editor metadata
\nare development artifacts, not consensus-critical state. Frequent package
\nreleases would create unnecessary permanent state churn, and CKB capacity costs
\nmake source-package storage especially unattractive.
The chain should probably record compact deployment facts and commitments, not
\nreplace the whole source distribution system.
A pure off-chain registry also seems insufficient.
\nFor production CKB contracts, builders and wallets need concrete deployment
\nidentity: CellDep, OutPoint, data_hash, dep_type, script/code hash checks,
\nschema/ABI commitments, and ideally provenance back to the source package,
\ncompiler version, and constraints report.
A compromised or stale source registry should not be enough to trick a
\nproduction builder into using the wrong deployed artifact.
Inspired by Move/Sui’s Move.toml / Move.lock / Published.toml separation,
\nbut adapted to CKB’s CellDep/OutPoint-based deployment model rather than Sui’s
\nnative package-object model.
Cell.toml continues to serve as the source-facing package manifest. No
\nstructural changes are required for registry support.
[package]\nname = \"amm\"\nversion = \"1.2.0\"\nnamespace = \"cellscript\"\n\n[dependencies]\ntoken = { version = \"0.3.0\", path = \"../token\" }\n\n[build]\ntarget_profile = \"ckb\"\n\n[deploy.ckb]\nhash_type = \"data1\"\ndep_type = \"code\"\n\n[[deploy.ckb.cell_deps]]\nname = \"secp256k1\"\nout_point = \"0x...:0\"\ndep_type = \"dep_group\"\nhash_type = \"type\"\nKey invariant: Cell.toml describes deployment intents (what hash_type
\nshould be), not deployment facts (which specific out_point was deployed to).
\nIntents are determined at compile time; facts are determined after deployment.
The [deploy.ckb] section already exists in the current Cell.toml schema.
\nThe compiler validates hash_type and dep_type values as compile errors, not
\nwarnings, because a builder that uses the wrong script hash mode or cell dep
\nmode can deploy a transaction that differs from the audited artifact identity.
The existing Cell.lock records dependency versions and sources. The registry
\nextension adds build identity hashes and deployment references.
Lockfile schema:
\nversion = 1\n\n[meta]\ncellscript_version = \"0.19.0\"\nlock_schema = \"cellscript-lock-v1\"\n\n[package]\nname = \"amm\"\nversion = \"1.2.0\"\nsource_hash = \"blake2b:0xabcd...\"\n\n[package.build]\ncompiler_version = \"0.19.0\"\ntarget_profile = \"ckb\"\nartifact_hash = \"blake2b:0x1234...\"\nmetadata_hash = \"blake2b:0x5678...\"\nschema_hash = \"blake2b:0x9abc...\"\nabi_hash = \"blake2b:0xdef0...\"\nconstraints_hash = \"blake2b:0x1111...\"\n\n[dependencies.token]\nversion = \"0.3.0\"\nsource = { path = \"../token\" }\nsource_hash = \"blake2b:0x2222...\"\nbuild = { artifact_hash = \"blake2b:0x3333...\", abi_hash = \"blake2b:0x4444...\" }\n\n[deployment.ckb.aggron4]\nstatus = \"deployed\"\nrecord = \"ckb-testnet:0x5678...\"\nrecord_hash = \"blake2b:0x9a9a...\"\n\n[deployment.ckb.mainnet]\nstatus = \"undeployed\"\nCross-file binding: The record field references the deployment by network
\nand identifier. The record_hash field is the Blake2b-256 hash of the
\ncorresponding [[deployments]] entry in Deployed.toml, serialized as
\ncanonical JSON (not canonical TOML). TOML has no standardized canonical
\nserialization; JSON does. This is consistent with the existing metadata_hash
\ncomputation in src/cli/commands.rs, which uses ckb_blake2b256(serde_json::to_vec(&metadata)).
The record_hash computation:
[[deployments]] TOML entry into a Rust struct.serde_json::to_string with sortedrecord_hash = ckb_blake2b256(canonical_json_bytes).Phase 1 makes record_hash optional: if present, cellc registry verify
\nchecks that it matches the actual Deployed.toml entry; if absent, the
\nverification step is skipped with a warning. Future phases may require
\nrecord_hash for production packages.
Backward compatibility: The lockfile uses a single version 1 schema.
\nThe [package.build] and [deployment.*] sections are optional; their absence
\nsimply means the package has not been built or deployed yet.
Key invariants:
\nCell.lock is the cryptographic bind point between source and deployment.Cell.lock, compiled artifacts, and Deployed.toml[deployment.*] section references deployment records in Deployed.tomlDeployed.toml.Deployed.toml is the CKB analogue of Move/Sui’s Published.toml. It is
\nautomatically generated by the deployment tool after the on-chain transaction is
\nconfirmed, and records immutable deployment facts derived from the chain.
Deployed.toml is generated by the CellScript deployment tool (cellscript-deploy
\nor the adapter crate’s CellScriptAdapter::deploy_artifact() API). It is not
\nhand-authored.
The generation path is trust-free by construction: the existing adapter crate
\narchitecture is headless-first, meaning all deployment facts are computed
\nlocally before the transaction is submitted, and the only chain-derived value
\nneeded after submission is the tx_hash.
Generation flow (matches existing deploy_artifact → build_deploy_transaction
\n→ build_deployment_manifest_from_evidence pipeline):
1. cellc build\n → produces artifact, metadata, constraints, schema, ABI\n → all build hashes computed locally (artifact_hash, metadata_hash,\n schema_hash, abi_hash, constraints_hash)\n\n2. build_deploy_transaction(spec)\n → headless: computes TYPE_ID args, data_hash, code_hash,\n occupied capacity, change output locally\n → returns (TransactionView, ResolvedDeployEvidence)\n → evidence already contains: code_hash, hash_type, type_id_args,\n artifact_hash, occupied_capacity, tx_size\n\n3. submit + wait_for_commitment\n → sends transaction through full node RPC\n → waits for committed status\n → receives tx_hash from the node response\n\n4. build_deployment_manifest_from_evidence(evidence, tx_hash, output_index)\n → constructs DeploymentManifest from locally-computed evidence + tx_hash\n → no get_transaction call needed: all hash fields already known\n → extends to Deployed.toml by adding network, chain_id, build section,\n and Cell.lock record_hash\nWhy no get_transaction / on-chain re-derivation is needed: The existing
\nadapter crate’s build_deploy_transaction already computes data_hash = blake2b(artifact_binary) locally (line 447 of lib.rs). The
\nResolvedDeployEvidence already carries code_hash, hash_type, and
\ntype_id_args. The only chain-derived value is tx_hash, which is returned
\nby send_transaction. The full node RPC is used for submission and commitment
\nwaiting, not for re-deriving fields that the tool already knows.
Verification path (not generation) is where on-chain reads happen:
\ncellc registry verify calls get_live_cell to confirm that the on-chain code
\ncell’s data matches data_hash in Deployed.toml. This separation of
\ngeneration and verification keeps the trust model clean: generation is
\nself-contained, verification is independently reproducible.
Data source requirement: Phase 1 requires a CKB full node RPC endpoint
\nfor transaction submission and commitment waiting (already required by
\nCellScriptAdapter::connect()). Verification additionally uses get_live_cell.
\nLight client support is a possible Phase 3 enhancement.
Immutability: Once generated, Deployed.toml must not be modified. Any
\nre-deployment or upgrade produces a new [[deployments]] entry with a distinct
\nset of chain facts, not an edit to an existing entry.
version = 1\nschema = \"cellscript-deployed-v0.19\"\n\n[package]\nname = \"amm\"\nversion = \"1.2.0\"\nsource_hash = \"blake2b:0xabcd...\"\n\n[build]\ncompiler_version = \"0.19.0\"\nartifact_hash = \"blake2b:0x1234...\"\nmetadata_hash = \"blake2b:0x5678...\"\nschema_hash = \"blake2b:0x9abc...\"\nabi_hash = \"blake2b:0xdef0...\"\nconstraints_hash = \"blake2b:0x1111...\"\n\n[[deployments]]\nnetwork = \"aggron4\"\nchain_id = \"ckb-testnet\"\nscript_role = \"type\"\ntx_hash = \"0xaaaa...\"\noutput_index = 0\ncode_hash = \"0xbbbb...\"\nhash_type = \"data1\"\ndep_type = \"code\"\nout_point = \"0xaaaa...:0\"\ndata_hash = \"0xcccc...\"\ntype_id = \"0xdddd...\"\n\n[[deployments.cell_deps]]\nname = \"secp256k1\"\ntx_hash = \"0xeeee...\"\noutput_index = 1\ndep_type = \"dep_group\"\nhash_type = \"type\"\n\n[[deployments]]\nnetwork = \"ckb-mainnet\"\nchain_id = \"ckb-mainnet\"\nscript_role = \"type\"\nstatus = \"candidate\"\nRelationship to existing DeploymentManifest: The current
\nDeploymentManifest type in crates/cellscript-ckb-adapter/src/lib.rs has
\nDeploymentRef with name/code_hash/hash_type/args/dep_type/out_point.
\nDeployed.toml is an enhanced deployment manifest that adds:
network and chain_id — which chain this deployment targetsscript_role — lock, type, dual-role, or helper dependencydata_hash — the data hash of the deployed code celltype_id — TYPE_ID upgrade lineage where applicablestatus — deployment lifecycle state[build] section — binding the deployment to build identityThe adapter crate’s load_deployment_manifest /
\nparse_deployment_manifest functions should be extended to support the new
\nschema while maintaining backward compatibility with the existing
\ncellscript-ckb-deployment-manifest-v0.19 schema.
Fields are classified by necessity:
\n| Field | \nPurpose | \n
|---|---|
network | \nWhich network this deployment targets | \n
chain_id | \nChain identifier | \n
tx_hash | \nDeployment transaction hash | \n
output_index | \nOutput index in deployment transaction | \n
code_hash | \nScript identity | \n
hash_type | \ndata / type / data1 / data2 | \n
dep_type | \ncode / dep_group | \n
data_hash | \nArtifact data hash | \n
out_point | \nCellDep reference | \n
| Field | \nPurpose | \n
|---|---|
artifact_hash | \nRISC-V binary hash | \n
metadata_hash | \nCompiler metadata hash | \n
schema_hash | \nSchema manifest hash | \n
abi_hash | \nABI hash | \n
constraints_hash | \nConstraints report hash | \n
compiler_version | \nCompiler version that produced the artifact | \n
| Field | \nPurpose | \n
|---|---|
type_id | \nTYPE_ID upgrade lineage | \n
script_role | \nlock / type / dual-role / helper | \n
status | \nactive / candidate / deprecated / revoked | \n
upgrade_lineage | \nTYPE_ID upgrade chain | \n
audit_report_hash | \nAudit report hash | \n
publisher_signature | \nPublisher identity signature | \n
deploy to network\n (undeployed) ─────────────────► candidate\n │\n confirm + │ revoke or\n audit pass │ supersede\n ▼ ▼\n active deprecated\n │\n supersede │\n ▼\n deprecated\n │\n revoke │\n ▼\n revoked\nA deployment record must not be treated as production-ready until its status
\nreaches active. The candidate state allows builders to preview and dry-run
\nagainst a deployment, but production transaction construction should require
\nactive status unless explicitly overridden.
The recommended approach is to start with a Git-repository-based lightweight
\nregistry index, similar to how crates.io uses a Git index, and evolve toward an
\nindependent service as ecosystem needs grow.
Rationale:
\nThe index repository is structured by namespace and name prefix, similar to
\ncrates.io’s Git index:
registry/\n├── cellscript/\n│ ├── amm.json\n│ └── token.json\n└── other-protocol/\n └── swap.json\nEach index record:
\n{\n \"name\": \"cellscript-amm\",\n \"namespace\": \"cellscript\",\n \"versions\": [\n {\n \"version\": \"1.2.0\",\n \"source_hash\": \"blake2b:0xabcd...\",\n \"source_archive\": \"sha256:0xef01...\",\n \"cellscript_version\": \"0.19.0\",\n \"dependencies\": {\n \"token\": \"0.3.0\"\n },\n \"abi_index\": \"blake2b:0xdef0...\",\n \"schema_hash\": \"blake2b:0x9abc...\",\n \"license\": \"MIT\",\n \"released_at\": \"2026-04-24T00:00:00Z\",\n \"yanked\": false,\n \"audit\": {\n \"report_hash\": \"blake2b:0x5555...\",\n \"acceptance_gate\": \"passed\"\n }\n }\n ]\n}\nSource packages are distributed as content-addressed archives:
\n.tar.gzsource_hash in the index is the Blake2b-256 of the canonical source treeCell.lock [package].source_hash)source_archive in the index is the SHA-256 of the .tar.gz fileThis two-hash scheme allows:
\nsource_archive (SHA-256)source_hash (Blake2b-256, matchingcellc ckb-hash)# Publish to the source registry\ncellc publish\n\n# Install from the source registry\ncellc install token@0.3.0\n\n# Verify package integrity against source and build artifacts\ncellc package verify\n\n# Verify deployment identity against chain facts\ncellc registry verify\nThe resolve_from_registry method in src/package/mod.rs currently returns
\nan error stating “registry dependency is not supported yet; use a local path
\ndependency.” The registry implementation replaces this stub with actual index
\nresolution, archive download, hash verification, and Cell.toml parsing.
Phase 1: Pure off-chain Deployed.toml records, verified through
\nCell.lock hash binding.
Phase 2: Optional on-chain type script index, driven by ecosystem demand.
\nRationale:
\nDeployed.toml + Cell.lock hash binding areThe builder must verify the full identity chain before constructing a
\nproduction transaction:
cellc build\n → generates artifact, metadata, schema, abi, constraints\n → writes Cell.lock [package.build]\n\ncellc deploy-plan\n → reads Cell.lock [package.build]\n → reads Cell.toml [deploy.ckb] intent\n → produces deployment plan JSON\n\nAfter deployment transaction is confirmed on-chain\n → generates Deployed.toml (chain facts)\n → updates Cell.lock [deployment.ckb.<network>]\n\ncellc registry verify\n → reads Cell.lock build hashes\n → reads Deployed.toml deployment facts\n → verifies:\n 1. source_hash matches between Cell.lock and Deployed.toml\n 2. artifact_hash matches between Cell.lock and Deployed.toml\n 3. data_hash = blake2b(artifact) against on-chain code cell\n 4. code_hash in Deployed.toml matches on-chain script\n 5. out_point is reachable as CellDep\n 6. schema_hash / abi_hash consistent with metadata\n 7. constraints_hash consistent with constraints report\n → any mismatch → FAIL CLOSED\nThe CellScript Action Builder (the v0.19 P0 target) consumes deployment
\nregistry records through the registry-client module:
┌──────────────┐ ┌──────────────────┐ ┌───────────────┐\n│ metadata- │ │ registry-client │ │ cell-resolver │\n│ loader │────►│ │────►│ │\n│ │ │ resolve package │ │ select live │\n│ load/validate│ │ resolve deploy │ │ cells via │\n│ metadata, │ │ verify hashes │ │ CCC/indexer │\n│ ABI, recipe │ │ against lockfile │ │ │\n└──────────────┘ └──────────────────┘ └───────────────┘\nThe registry-client module is responsible for:
Deployed.toml.Cell.lock.The Action Builder must not accept a package by name alone. It must verify that
\nthe resolved source package, build artifact, constraints report, and CKB
\ndeployment identity all match.
The constraints_hash field is critical for deployment safety: it binds the
\ndeployment to the exact set of constraints the compiler generated, preventing
\na compromised constraints report from being substituted after deployment.
Phase 1 approach — same-version stability: cellc build generates
\nconstraints_hash using the same method as the existing metadata_hash
\ncomputation:
constraints_hash = ckb_blake2b256(serde_json::to_vec(&constraints))\nThis matches the existing pattern in src/cli/commands.rs where
\nmetadata_hash is computed as ckb_blake2b256(serde_json::to_vec(&result.metadata)).
Determinism guarantees in Phase 1:
\nConstraintsMetadata struct → same serde_json::to_vec output → sameconstraints_hash. This is sufficient for Phase 1 because constraints_hashConstraintsMetadata struct fields are ordered by Rust struct fieldentry_abi, runtime_errors, warnings, failures) areKnown limitation: Cross-compiler-version constraints_hash comparison is
\nnot supported and should not be attempted. The metadata_schema_version field
\nin CompileMetadata serves as the version gate — if schema versions differ,
\nverification must reject the comparison, not attempt hash matching.
Phase 2 enhancement: For stronger cross-build determinism (e.g.,
\nverifying that two independent builds of the same source produce the same
\nconstraints_hash), the ConstraintsMetadata struct should:
Vec fields by a stable key (entry_name, code, etc.)HashMap with BTreeMap for key orderingserde_json serialization to compact output with sorted keysThese changes are backward-compatible: they only affect the hash computation,
\nnot the schema. A Phase 2 migration can compute both the old and new hashes
\nto bridge the transition.
Hello everyone, fiber-pay v0.2.5 is out, and this release brings the ConnectButton component to @fiber-pay/react — a one-line drop-in for connecting a Fiber browser node with explicit passkey or password strategy.
ConnectButton — A unified connect/disconnect button that works in standalone mode (<ConnectButton network=\"testnet\" strategy=\"passkey\" />) or pairs with an existing useFiberNode hook for shared state across your app.useFiberNode hardening — Fixed StrictMode remount reliability so async state updates don’t get dropped during React effect re-runs.ConnectButton-first auth flow, showing how the component fits into a real wallet console.FiberPayQuickCard payment integration.If you’re building a frontend that accepts Fiber payments, you can now add a connect button and payment card with a few imports — no need to wire up node lifecycle, passkey detection, or connection state yourself. The component handles the boilerplate and exposes hooks for customization when you need it.
\nThe interesting calling-agent demo is built using such an SDK. You can also check out the browser-wallet and react-quick-card demos in the repo, or grab the package:
\npnpm add @fiber-pay/react\nLet me know if you try it out or have feedback on the API!
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10231, "title": "Tiko Creator Commerce Expansion + Private Beta Validation", "slug": "tiko-creator-commerce-expansion-private-beta-validation", "url": "https://talk.nervos.org/t/tiko-creator-commerce-expansion-private-beta-validation/10231", "created_at": "2026-05-06T07:46:28.834000+00:00", "last_posted_at": "2026-05-06T07:46:28.918000+00:00", "category_id": 49, "tags": [ "Spark-Program" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24146, "post_number": 1, "topic_id": 10231, "topic_title": "Tiko Creator Commerce Expansion + Private Beta Validation", "topic_slug": "tiko-creator-commerce-expansion-private-beta-validation", "author": "DWSQUIRES", "created_at": "2026-05-06T07:46:28.918000+00:00", "updated_at": "2026-05-06T09:17:07.884000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/tiko-creator-commerce-expansion-private-beta-validation/10231/1", "content_text": "1. Project Name\nTiko Creator Commerce Expansion + Private Beta Validation\n2. Team / Individual Profile\nProject: Tiko\nType: Ticketing and creator commerce platform built on CKB\nLead: Indie Developer\nContact: Discord- @getigeti21\nI have already built the live ticketing foundation of Tiko, including event\nlisting, checkout, CKB testnet payment confirmation, ticket issuance, QR-based\naccess, operator check-in, and Spore-backed ownership. The current product is\nalready testable and demonstrates the core event commerce flow working end to\nend on CKB testnet.\nGitHub: GitHub - Tiko-T/Tiko · GitHub\nLive website: https://tiko-pied.vercel.app/\nCurrent test access\nEmail: admin@tiko.local\nPassword: 7V8ogwFc845anR1SqX2HLcZ3xojx0CRT\nHow to test the live product\nOpen the live website.\nSign in with the test credentials above.\nBrowse the available event listing.\nOpen the event details page and proceed to checkout.\nComplete the wallet-based payment flow on CKB testnet. (Use this to claim our internal Token Faucet )\nSubmit the payment transaction hash.\nVerify ticket issuance, QR-based access, and post-purchase ownership flow.\nI am applying for Spark support to build the next stage of Tiko: expanding it\nfrom a working ticketing product into a broader creator commerce offering, and\nthen running a short private beta to validate that expanded product with real\nusers.\n3. Project Description\nProblem\nMost event and creator platforms are fragmented.\nA creator may use:\none tool for events\none tool for digital products\none tool for memberships\none tool for fan rewards\nanother tool for authenticity or collectible ownership\nThat creates a broken experience for both creators and fans. Ticketing is\ndisconnected from post-purchase engagement, digital commerce is disconnected\nfrom community access, and blockchain ownership often exists separately from\nusable product workflows.\nSolution\nTiko combines ticketing and creator commerce into one product.\nThe existing product already handles event ticketing. This Spark proposal\nfunds the next layer: turning Tiko into a platform where creators and\noperators can sell not only event access, but also digital drops, memberships,\ncollectibles, bundles, and post-purchase rewards, while using CKB and Spore\nonly where blockchain adds real product value.\nExisting Product State\nAlready working:\nevent listing and publishing\nticket checkout flow\nCKB testnet payment confirmation\norder tracking\nticket issuance\nQR access and operator check-in\nbuyer wallet linking\nSpore-backed ownership after purchase\nWhat This Grant Will Build\nThis grant will implement the next 7 creator commerce components:\nDigital drops\nCreator-led downloadable or unlockable products such as artwork, media,\ntemplates, and exclusive files.\nMemberships and passes\nFan club style access products, VIP passes, and community memberships.\nLimited editions and collectibles\nEditioned creator items and event collectibles with Spore-backed ownership\nand provenance.\nPost-purchase fan rewards\nBonus drops, proof-of-attendance rewards, and follow-up perks tied to\nticket purchases.\nGated access products\nContent or product pages accessible only to qualifying buyers, members, or\nholders.\nPhysical merchandise with authenticity\nProduct flows for premium merchandise paired with digital authenticity\nproof.\nBundles\nCombined offers such as ticket + collectible, membership + exclusive\ncontent, or event access + replay + premium item.\n4. Why This Fits Spark\nThis project is a strong Spark fit because:\nit extends a working prototype rather than starting from zero\nit can produce a meaningful prototype expansion within 1-2 months\nit combines technical development and early user validation\nit clearly aligns with Web5 thinking: familiar Web2 UX with Web3 ownership\nwhere useful\nit solves a practical ecosystem need rather than building speculative\ninfrastructure\nThis is not a pure experiment without delivery. It is a focused expansion of\nan already working product into a more complete creator-commerce use case on\nCKB.\n5. Expected Deliverables\nBy the end of the grant period, I will provide:\nProduct Deliverables\ncreator commerce product expansion inside Tiko\nsupport for the 7 creator commerce product types listed above\nupdated creator-facing listing and management flows\nupdated buyer-facing product discovery and purchase flows\nbeta-ready private test environment\nTechnical Deliverables\npublic open-source code repository updates\ndeployment instructions\nconcise product and technical documentation\nlive or recorded product demo\nbeta flow walkthrough\nUser Validation Deliverables\nstructured private beta with early users\nuser feedback summary\nproduct learning report\nproposed post-beta iteration roadmap\n6. Estimated Completion Time\n1.2 months\nPlanned execution window: 5 weeks\n7. Clear To-Do List\nWeek 1\nfinalize creator commerce scope in product and UI terms\nadd product models and flows for digital drops, memberships, collectibles,\nand bundles\nprepare creator-facing management structure\nWeek 2\nimplement buyer-facing flows for creator commerce items\nconnect fulfillment logic for non-ticket products\nintegrate gated access and post-purchase reward hooks\nWeek 3\nimplement authenticity-oriented physical merch support at prototype level\nfinish collectible and reward issuance flow\nconnect creator commerce items into buyer library and ownership views\nWeek 4\ninternal QA and end-to-end testing on CKB testnet\nprepare private beta environment\nonboard early testers and selected creators\nWeek 5\nrun private beta\ncollect structured feedback\nsummarize user insights, friction points, and adoption signals\npublish completion report, demo, repo updates, and learnings\n8. User Testing Plan\nThis project includes a real early-validation phase, not just feature\ndelivery.\nPrivate Beta Goals\nvalidate whether creators understand the combined ticketing + creator\ncommerce offering\nvalidate whether buyers understand and adopt non-ticket creator products\ntest which of the 7 creator commerce components feel most valuable in\npractice\nidentify where blockchain-backed ownership improves user trust or retention\nPlanned Beta Scope\n3-5 early creators / operators\n20-30 users\nstructured feedback collection through direct testing and product\nobservation\ntrack usage across listing, purchase, fulfillment, and post-purchase access\nWhat I Want to Learn\nwhich creator commerce components are most commercially attractive\nwhat creators want to sell alongside tickets\nwhether buyers understand and value ownership-backed creator products\nwhere the current product flow is too complex\nwhat should become the next priority after Spark\n9. Required Funding\nRequested amount: $1,850\nSuggested funding composition\n50% USDI\n50% CKB equivalent\n10. Funding Breakdown\nDevelopment and product implementation — $1,050\ncreator commerce flows and UI expansion\nfulfillment logic for new product types\ngated access and bundle behavior\ncollectible/reward flow integration\ndeployment and environment iteration\nBeta testing and user validation — $500\nUser recruitment support\nbeta coordination\ncreator onboarding for testers\nfeedback collection and synthesis\ndemo preparation and reporting\nInfrastructure and operational costs — $300\ntest deployment operations\nstorage and service costs\nenvironment maintenance during beta\nsmall contingency for product iteration during testing\n11. Relevance to the CKB Ecosystem\nThis project is directly relevant to the CKB ecosystem because it uses CKB and\nSpore in a product-shaped way that real users can understand.\nPractical ecosystem relevance\ndemonstrates a real end-user ticketing and commerce flow on CKB\nexpands CKB usage beyond payments into ownership, authenticity, and rewards\nshows how Web2-style UX and Web3 ownership can coexist\ncreates a practical reference product for creator commerce on Nervos\nWhy CKB matters here\nCKB is not being used as decoration. It provides:\nownership-backed product fulfillment\nSpore-based provenance for creator items\na foundation for collectible, authenticity, and reward flows that make sense\nfor creators and fans\nThis is aligned with the ecosystem goal of building practical Web5 products\nthat connect real user workflows with blockchain-backed value.\n12. Alignment With Web5 Philosophy\nThis proposal strongly aligns with the Web5 direction described by Spark:\norganic combination of Web2 and Web3\nBuyers browse and purchase through a familiar web flow, while blockchain is\nused where it adds ownership and trust.\nuser-centric and human-oriented\nThe focus is not on protocol complexity but on creator products, audience\nrelationships, and useful buying experiences.\nsmall but real\nThe scope is intentionally sized for a 5-week cycle and tied to concrete\nprototype and beta outcomes.\nprototype plus feedback loop\nThe proposal includes both implementation and real user validation.\n13. Open Source Commitment\nYes.\nAll work delivered under this Spark proposal will remain open source and will\nbe published through the existing repository.\n14. Completion Outputs\nAt completion I will provide:\nupdated open-source repository\nproduct demo\nshort implementation summary\nprivate beta report\nkey user feedback findings\ncomparison of planned scope vs actual completed scope\nrecommendations for next-stage iteration\n15. What Success Looks Like\nThis Spark project will be successful if, by the end of the cycle:\nTiko supports creator-commerce flows beyond tickets\nthe 7 proposed components exist as connected prototype capabilities\ncreators can understand the broader product offering\nbuyers can successfully use at least part of the expanded commerce flow\nearly beta feedback reveals which components have strongest market pull\nthe CKB ecosystem gains a concrete creator-commerce reference product\n16. Closing Summary\nTiko already proves that ticketing on CKB can work in a real, user-facing way.\nThis grant will help prove the next step:\nthat ticketing can become the foundation for a broader creator commerce\nplatform, where creators sell access, digital drops, memberships,\ncollectibles, bundles, and authenticity-backed products from one system.", "content_html": "Tiko Creator Commerce Expansion + Private Beta Validation
\nProject: Tiko
\nType: Ticketing and creator commerce platform built on CKB
\nLead: Indie Developer
\nContact: Discord- @getigeti21
I have already built the live ticketing foundation of Tiko, including event
\nlisting, checkout, CKB testnet payment confirmation, ticket issuance, QR-based
\naccess, operator check-in, and Spore-backed ownership. The current product is
\nalready testable and demonstrates the core event commerce flow working end to
\nend on CKB testnet.
GitHub: GitHub - Tiko-T/Tiko · GitHub
\nLive website: https://tiko-pied.vercel.app/
Current test access
\nHow to test the live product
\nI am applying for Spark support to build the next stage of Tiko: expanding it
\nfrom a working ticketing product into a broader creator commerce offering, and
\nthen running a short private beta to validate that expanded product with real
\nusers.
Most event and creator platforms are fragmented.
\nA creator may use:
\nThat creates a broken experience for both creators and fans. Ticketing is
\ndisconnected from post-purchase engagement, digital commerce is disconnected
\nfrom community access, and blockchain ownership often exists separately from
\nusable product workflows.
Tiko combines ticketing and creator commerce into one product.
\nThe existing product already handles event ticketing. This Spark proposal
\nfunds the next layer: turning Tiko into a platform where creators and
\noperators can sell not only event access, but also digital drops, memberships,
\ncollectibles, bundles, and post-purchase rewards, while using CKB and Spore
\nonly where blockchain adds real product value.
Already working:
\nThis grant will implement the next 7 creator commerce components:
\nThis project is a strong Spark fit because:
\nThis is not a pure experiment without delivery. It is a focused expansion of
\nan already working product into a more complete creator-commerce use case on
\nCKB.
By the end of the grant period, I will provide:
\n1.2 months
\nPlanned execution window: 5 weeks
This project includes a real early-validation phase, not just feature
\ndelivery.
Requested amount: $1,850
\nThis project is directly relevant to the CKB ecosystem because it uses CKB and
\nSpore in a product-shaped way that real users can understand.
CKB is not being used as decoration. It provides:
\nThis is aligned with the ecosystem goal of building practical Web5 products
\nthat connect real user workflows with blockchain-backed value.
This proposal strongly aligns with the Web5 direction described by Spark:
\nYes.
\nAll work delivered under this Spark proposal will remain open source and will
\nbe published through the existing repository.
At completion I will provide:
\nThis Spark project will be successful if, by the end of the cycle:
\nTiko already proves that ticketing on CKB can work in a real, user-facing way.
\nThis grant will help prove the next step:
\nthat ticketing can become the foundation for a broader creator commerce
\nplatform, where creators sell access, digital drops, memberships,
\ncollectibles, bundles, and authenticity-backed products from one system.
这是我最近比较着迷的一个方向：通过 fiber 在浏览器里付费调用别人电脑上的 opencode/claude code/codex 这些 Agent，去执行某些任务。有点像 AI 公司推出的云端 Agent，用户可以直接在云服务器上调用去执行任务，不用自己在本地部署这些 Agent，对于不懂技术的用户来说体验会比较简单。
\n\n我们这个尝试不太一样的地方是，我们的后端是一个开放服务，不是某个中心化的公司来提供这样的云端 Agent，而是分布式的，每个人都能提供这样的服务。调用 Agent 的用户和提供 Agent 的用户通过 Fiber 做即时的结算，目前我的尝试比较简单，是按次来收费的，调用一次就收一次固定的费用。后面如果做得更精细一点，应该是按 input 和 output token 的用量来收取费用。这个在技术上不是问题，只是一个适配的问题。
\n我做这个的一个目的，是想看看是不是能解决 LLM API 中转的一些问题。我知道目前有许多 API 中转站，用来给某些无法享受 Claude / codex 的用户提供相应的 API。API 这种模式很多时候要依赖中转站的质量，同时最上游的 LLM 也比较容易通过一些检查去查到 API 滥用/转用的情况。如果是直接调用 Agent 的话（比如 opencode/ claude code），应该更容易分享，平台也更难检测，因为理论上我也还是在用 claude code 的 CLI 去使用 claude，只不过是别的用户通过我的电脑来使用而已。而且因为这个服务是去中心化的，由许多用户来自主提供，应该更不容易被封禁？最后还有个好处是，Agent 的能力一直在不停进化，用户只要升级 Agent 的版本就能跟上最新的能力，不需要我们这个平台做任何的改变，模式更灵活。
\n说回 fiber。这个尝试我从头到尾做了比较完整的实现，想提供完善的用户体验，不想只是做可行性验证而已。按次付费我主要是通过 l402 的风格来实现的，这部分我借助 fiber-pay 很容易就跑起来了，我这个服务甚至不需要自己写一个专门的后端程序，只是使用 fiber-pay 的 CLI 跑一跑命令而已。更多的问题其实是在 agent 的 runtime 层的封装上。比如，需要使用 boxlite 这样的容器去隔离一个环境，让 agent 能比较安全的在自己的电脑上运行，这样确保提供服务的人不会被某些恶意用户攻击；还需要能去支持调用不同的 agent，这部分借助于 openclaw 提供的 acpx 库可以节省不少力气；最后还需要考虑提供 Agent 的用户不会把敏感信息泄露出来的（比如 Agent 配置的 API key），这部分我做了一些容器内外的环境变量替换来规避这个问题。总的来说，这样一个服务，更多的工作都落在业务层面上， Fiber 的部分反而是里面比较容易解决的。这应该是比较合理的现象。
\n我觉得如果我们能从一个比较小的、具体的、真实存在的问题出发，通过 Fiber 尝试一些解决方案，可能我们会找到更多有潜力的应用方向。同时，Fiber 的 wasm 能力可以提供很不错的用户体验，尤其是跟 passkey 结合在一起，这在通道网络技术竞争中可能是一个不错的差异化的点。我把我这次尝试的应用分享在这里：https://calling-agent-kappa.vercel.app/ 感兴趣的朋友可以试用一下，目前服务的 Agent 是我在家里的一台小主机上跑的 opencode，LLM 是用的 kimi 模型，付费暂时还是基于 fiber 测试网在跑，每次调用 0.1 CKB。如果各位觉得这个想法值得探索，我们可以部署到主网上去跑，我很期待能有用户愿意去跑 claude code 这样的 agent 服务，至少作为需求方，我现在还没法完整的使用 claude code 这样的 Agent，挺需要有类似的服务。我相信如果定价合适的话，应该是对提供商和用户双方都有利的情况。
", "like_count": 0, "quote_count": 0 }, { "post_id": 24141, "post_number": 2, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "janx", "created_at": "2026-05-06T04:45:37.393000+00:00", "updated_at": "2026-05-06T04:45:37.393000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/2", "content_text": "Love the UX presented by “running a fiber node in browser” + integrated passkey wallet - it’s rare to be both smooth and trustless.", "content_html": "Love the UX presented by “running a fiber node in browser” + integrated passkey wallet - it’s rare to be both smooth and trustless.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24142, "post_number": 3, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "ArthurZhang", "created_at": "2026-05-06T05:57:10.576000+00:00", "updated_at": "2026-05-06T05:57:10.576000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/3", "content_text": "This is a really solid end-to-end implementation. A friendly thought on the architecture though, instead of wrapping each agent manually, why not just look at how popular platforms handle MCP + Skills? If the goal is to build an open network, migrating to an MCP + Skills architecture might greatly improve extensibility.", "content_html": "This is a really solid end-to-end implementation. A friendly thought on the architecture though, instead of wrapping each agent manually, why not just look at how popular platforms handle MCP + Skills? If the goal is to build an open network, migrating to an MCP + Skills architecture might greatly improve extensibility.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24143, "post_number": 4, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "RetricSu", "created_at": "2026-05-06T06:24:22.903000+00:00", "updated_at": "2026-05-06T06:24:22.903000+00:00", "reply_to_post_number": 3, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/4", "content_text": "如果我没理解错的话，mcp/skills 是更偏配套给 Agent 用的协议，目标是让 Agent（大脑）可以使用各种工具（手脚），通常并不直接用来调用 Agent ？\n调用 Agent 的协议主要是A2A (google 提出的), ACP(Agent Communication Protocol) (IBM提出的，目前是 A2A 的一部份)、ACP(Agent Client Protocol)(zed提出的) 这类协议。目前我们并不是手动封装每一种agent，而是用的 acpx 这个无头 CLI 工具，acpx 是通过 CLI 的形式实现的最后一种 ACP 协议的客户端。\n另外提一句，CLI/MCP/Skills 都是有趣的形式，彼此都在发挥作用，这里我选择 CLI 在实现操控 Agent 上是更容易适配的，考虑到大部分 Agent 本身都是 CLI 客户端的形式。", "content_html": "如果我没理解错的话，mcp/skills 是更偏配套给 Agent 用的协议，目标是让 Agent（大脑）可以使用各种工具（手脚），通常并不直接用来调用 Agent ？
\n调用 Agent 的协议主要是A2A (google 提出的), ACP(Agent Communication Protocol) (IBM提出的，目前是 A2A 的一部份)、ACP(Agent Client Protocol)(zed提出的) 这类协议。目前我们并不是手动封装每一种agent，而是用的 acpx 这个无头 CLI 工具，acpx 是通过 CLI 的形式实现的最后一种 ACP 协议的客户端。
\n另外提一句，CLI/MCP/Skills 都是有趣的形式，彼此都在发挥作用，这里我选择 CLI 在实现操控 Agent 上是更容易适配的，考虑到大部分 Agent 本身都是 CLI 客户端的形式。
", "like_count": 0, "quote_count": 0 }, { "post_id": 24145, "post_number": 5, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "ArthurZhang", "created_at": "2026-05-06T07:31:14.664000+00:00", "updated_at": "2026-05-06T07:31:14.664000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/5", "content_text": "Thanks for the clarification, you’re right. i just realised that one could theoretically wrap an Agent as an MCP Server to expose it indirectly, but that’s a workaround,and semantically awkward, since an MCP Server is a tool called by an Agent, not an Agent called by a user.", "content_html": "Thanks for the clarification, you’re right. i just realised that one could theoretically wrap an Agent as an MCP Server to expose it indirectly, but that’s a workaround,and semantically awkward, since an MCP Server is a tool called by an Agent, not an Agent called by a user.
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10228, "title": "DAO Structures and the future of Ai agents (aspirational piece)", "slug": "dao-structures-and-the-future-of-ai-agents-aspirational-piece", "url": "https://talk.nervos.org/t/dao-structures-and-the-future-of-ai-agents-aspirational-piece/10228", "created_at": "2026-05-05T20:28:13.169000+00:00", "last_posted_at": "2026-05-06T03:05:00.511000+00:00", "category_id": 31, "tags": [], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24135, "post_number": 1, "topic_id": 10228, "topic_title": "DAO Structures and the future of Ai agents (aspirational piece)", "topic_slug": "dao-structures-and-the-future-of-ai-agents-aspirational-piece", "author": "Eyeam", "created_at": "2026-05-05T20:28:13.233000+00:00", "updated_at": "2026-05-05T22:25:06.625000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dao-structures-and-the-future-of-ai-agents-aspirational-piece/10228/1", "content_text": "How can Nervos CKB Utilise AI agents?\nMy Personal Theory on how a CKB DAO should/could function in the future.\nThis is a disclaimer. This is not going to be implemented in anyway to any current DAO design.\nAI agents are something I’ve been predicting for the last few years now for DAO usage. I’ve even enjoyed a debate or two with Jan Xie, the architect of Nervos CKB during a jaunt to Thailand about how AI agents could/should be used for DAO’s in the future. I’ve spoken of them to various people within the ecosystem at different times. They are needed, (in my opinion) to smooth out the whole process of regulating human interaction, social cohesion, and be conducive to efficient governance and financial settings regarding proposals within a CKB community DAO. They can also add less party political aspects that often are toxic in human competition.\nAfter experiencing and seeing many problems in many current DAO’s (including the CKB community DAO), I’ve decided to explain why my interest has only heightened in the journey for DAO’s to be regulated by AI agents. This is all THEORETICAL rambling, but let’s call them CK Agents for now. (Common Knowledge Agents)\nCK agents have the chance to significantly enhance the maintenance and operation of the CKB community DAO, whilst preserving mutual community governance as the ultimate authority.\nThat ultimate authority is the core value we must strive towards for CKB. The ability to trust parties seems like a basic thing to take for granted, but a POW blockchain is all about removing trust assumptions in general (or certainly lowering them) and personally I’m all for that process!\nThe CK agents will be tireless, programmable extensions of the community, handling repetitive, data-heavy and time-sensitive tasks that humans find burdensome, whilst preventing the seizing of control by the CK agents themselves.\nThis keeps the DAO truly “autonomous” (it puts the “A” in DAO) while making it more efficient, scalable, and resilient to outside influence or bad actors. Until this system is applied, I refuse to call it a DAO. It should just be called a ‘DO’ currently.\nIn practice, a CK agent is an autonomous software entity (powered by LLMs, reinforcement learning, or multi-CK agent systems) that interact directly with the CKB blockchain, smart contracts, oracles, and off-chain data.\nThey can be deployed, updated, or revoked through standard CKB DAO governance votes, to ensure alignment with the Nervos communities needs and will.\nComputations might mainly be run off-chain (for cost/speed) with cryptographic proofs (like zero-knowledge proofs), verified on-chain for transparency for all to acknowledge.\nBelow are a few paradigms of how these agents could affect change for the Nervos CKB community.\nStreamlining Governance\nProposal summarisation and analysis: CK agents could read long proposals, forum discussions and on-chain data. They could generate neutral summaries, simulate financial impacts of the treasury, could include market efficiency of payout periods, flag unseen risks, and could even respond with counter-proposals/refinements based on the CKB community guidelines.\nThe problem with smaller community DAO’s in my experience is voter apathy due to technical limitations of the voter. By making complex decisions easier to understand, CKB holders are often thrown into a minefield of complexity for the community, especially when timelines and technical details are lost upon them. (A current common occurrence) Not to be confused with a limited voting community. (A whole separate argument not solved by CK Agents)\nIntelligent voting delegation: CKB holders could potentially create personalised “CK voting agents” encoded with their own preferences (e.g. risk tolerance, priorities via simple questionnaires). The CK agent then votes automatically on proposals that match those rules. Our token holders could also retain or override rights at any time. This restricts the forcing of constant human involvement. If the community members cannot create these agents, a proposal could be made for a CK Agent creator dApp that allows them to create their own, very easily at the push of a button. (perhaps this is a game changing dApp that could be utilised across the whole DAO space and not just CKB’s).\nOutcome simulation and recommendations: Before a community vote, CK agents could potentially run a scenario model (e.g., “What if this treasury allocation passes?”) using historical CKB DAO data and market signals. They can provide interpretable reports to inform voters so they do not remain ill informed.\nThe CKB DAO voters can act on the agent’s core logic, boundaries, or model updates which of course will update by voting as the DAO matures in the legal framework. We will come to legal frameworks later.\nThe CKB Treasury Fund\nTreasury optimisation: CK agents could potentially handle any foundation or projects payrolls, CKB grants, or disperse private proposal pay outs once approved. This reduces the need for a CKB human internal committee, it may reduce the need for human friction in decision making, reduce the need to pay any committee members, and become more sustainable long term. In fact it could reduce the bus factor for Nervos CKB or any projects looking to become long term, or even help out running a small team for a developer who is lacking in man power (What is the bus factor?).\nRoutine execution: CK Agents could trigger smart contract actions like CKB/iCKB token distributions, SPORE mints, or cross-chain bridges such as the Rosen Bridge. In the event CKB becomes DeFi-focused, they could potentially perform arbitrage, staking, or lending autonomously without human trust. CKB is modelled for decentralisation so it’s the perfect use case.\nAdministrative tasks: They could schedule community or dApp team meetings, manage CKB contributor bounties, or generate reports ensuring humans need not create high-level strategies. This reduces the risk of bad decision making and bases it on projected game theories.\nSecurity, and Compliance\nReal-time oversight: CK Agents could scan transactions for anomalies, hacks, or compliance issues (e.g. unusual outflows/Tx’s), automatically pause contracts or alert the community through on-chain notifications 24 hours a day through whatever social or device you prefer.\nRisk mitigation: They could reconcile accounts, enforce rules ( e.g. multi-sig requirements), and provide predictive insights on potential vulnerabilities within the CKB DAO structure, and act as oracles to alert community members when they are venturing into bad faith actions, but not censorship. Transparency is still and will always be needed.\nDispute resolution support: In some setups, CK agents could analyse evidence neutrally for the community arbitration. A very valuable process to remove emotion from decision making, but not entirely, because ultimately DAO’s often create controversy as we currently see on Talk.Nervos.org from time to time with proposals being ill thought out or controversial to spending.\nCommunity Engagement\nDiscussion facilitation: They could summarise social media, Discord and Talk.nervos forum threads, identify consensus, or moderate spam while surfacing diverse opinions/voices and bringing them to the forefront of the debate.\nIdea generation: CK Agents could brainstorm CKB proposals based on community sentiment, external trends, or bring forth exciting new ideas made from communities historical inputs, then be refined with human scepticism. Most of the time LLM’s don’t invent things, but they’re great at aggregating information to help generate more informed ideas. A CK agent will write your proposal for you with the right prompts, allowing you to bridge the ‘basic member’ to the experts. (with ease)\nSwarm intelligence DAO’s: AI agents from different DAOs could act as “liaisons,” enabling automated collaboration and joint ventures, without manual coordination. This could create a network of interconnected DAOs, either interoperable with other blockchains or multiple DAOs within the CKB ecosphere.\nExperimental Usecases\nCKB developers could create tokenised autonomous agents that operate as “CKB community DAO members” with their own Neuron wallet or with decision rights, bounded by governance. An interesting game changing prospect for Nervos CKB.\nThere could be Multi-CK agent systems for complex tasks where they work in unison together to perform tasks that all slot together like an overall process, much like a ‘Jigsaw’. Modular, but running in sync.\nThese CK agents should be open sourced, and in the era of quantum computing, they will no doubt have to adapt and evolve to be quantum resistant to remain future proof. A general ethos of CKB’s flexibility and tenacious personality.\nThey should be run on decentralised computer networks to avoid single points of failure and ideally they could be upgraded through governance proposals and voted on by the CKB community, whilst having on-chain logs of actions, verifiable outputs (e.g. using ZKP proofs) and work only within the boundaries of the communities decision making.\nRegular reviews and audits would have to be applied so they align with ongoing updates to the Nervos CKB ethos.\nThe Legal aspect\nIn theory DAO’s could pose legal risks and problems. Whilst CK agents cannot remove all the grey areas in an ever evolving regulatory framework, they could meaningfully mitigate risks, reduce exposure to grey areas, and strengthen legal defence when deployed as community-governed tools.\nThey would act as regulatory technology layers, automation monitoring, analysis, and enforcement, while keeping the CKB community in ultimate control. Mandatory.\nCK agents actions would be legally attributed to the community DAO, not the CK agents themselves. CK agents would have no legal personhood, but who knows in the future whether that will remain the case?\nAdaptive Compliance\nCK Agents could continuously scan global regulations, court rulings, and real time legislative updates.\nThey could flag potential impacts on the CKB DAO’s operations such as the treasury, CKB tokenomic emissions, cross-border Tx’s and vote adjustments*.*\nThe Nervos community could create a DAO proposal and vote for CKB developers to code “Compliance Monitoring Agents” that can track changes across global jurisdictions, reducing potential violations and reducing legal complications or friction.\nWorkflows, data privacy, and a country’s SEC rules, might also be encoded to the CK agents, with significant legal benefits that are auditable and can be proven in a court of law that members have acted in good faith within legal environments.\nPre Execution\nBefore any on-chain action (proposal execution, treasury transfer, or governance vote), CK agents could analyse it against known regulatory tests (e.g. The Howey test for securities, travel rule for virtual assets, or risk classifications).\nThey could simulate outcomes (“Would this look like an unregistered offering?”) and flag grey-area risks with transparent reason logs (provable via on-chain or ZKP-veri outputs).\nCK agents could contain tools to check for compliance red flags, and prevent malicious or risky actions from reaching to the point of execution.\nLegal benefit would shift from a reactive “battlefield” of defence, and switch to preventive guardrails. There could be human/community reviews required for high-stakes decisions, thus avoiding legal problems\nTransparency and Audit Trails\nEvery AI decision, reasoning, and data source could be logged immutably on-chain or with verifiable off-chain storage, generating tamper-proof compliance reports, impact assessments, and decision rationale.\nIn a regulatory investigation, the Community DAO could demonstrate that actions followed encoded rules aligned with community consensus, and not arbitrary human discretion.\nA legal benefit could strengthen defensibility in grey areas by proving transparency and process adherence, which is harder for regulators to challenge than opaque, human-led, decisions.\nAutonomy and Human ‘Watchers’\nCK agents might operate within strict, DAO-voted bounds (e.g. large sums having kill switches and revocation rights), combining the automation of the CK agents with human oversight.\nMulti-CK agent systems (risk assessments, amongst others, for execution, reduce single-point failures.) AI is treated as a tool under agency law principles, deployers remain accountable and they could provide legal shields for any mis-programming.\nLegal Wrappers and Insurance\nCK agents might use DAO legal entity jargon. A type of ‘Legal wrapper’. The agent could operate on behalf of the CKB community DAO which would be its own registered entity.\nCK agents might even help maintain compliance documentation like ‘fiduciary duty tracking’.\nCK agents could be encoded with dedicated insurance for AI actions, and monitoring to trigger claims or pauses in a court of law.\nLimitations Create New Grey Areas\nBut let’s not kid ourselves, CK agents (and indeed any AI agent) cannot give legal advice. They would only be recommendations that will not be legally binding due to the earlier point of CK agents not having a person-hood status. With new technology, comes lack of legislation. New risks could emerge such as ‘agent hallucinations’ (examples here), bias, or over-automation, which could create fresh liabilities. Human oversight is in fact non-negotiable to ensure these blips are correctable at code level.\nHuman rights may even come into play and have legal ramifications, which might be different in other countries and vary in legislation. AI agents are today transforming compliance in traditional finance and could be adapted to DAOs already. The CK agent will have a lot to navigate to mimic the growing trends in legalese, and may even have to be consorted by a lawyer before being programmed and installed.\nA Final Food For Thought.\nCK agents won’t erase the legal battlefield, they may carry the potential to equip the community DAO with better reconnaissance, automated defences, and verifiable records to navigate our communities decisions more safely. They could even maximise the potential for the legality to be ‘pro active’ as opposed to being ‘reactive’ in today’s modern world.\nBut we must remember, AI assists, it will not replace the legality of the CKB community DAO.\nSo let’s keep CKB decentralised and community-governed, because the key is to design agents to be the tools, and not the rulers of the Nervos DAO!!\nCK agents might just supercharge the whole DAO process and make them as autonomous as they can be, without replacing our governance and decision making entirely. The future is for the community to make.\nCK or AI agents are very much just a pipe dream currently in regards to DAO structures, but in the future I have no doubt they will have a part to play once more efficient.\nFeel free to comment or take any ideas from this to debate.\nThe question is, how far do you think we are away from these things being effective?\nDo you trust Ai even if its kept in human check?\nDoes it take the fun away and the social element?", "content_html": "How can Nervos CKB Utilise AI agents?
\nMy Personal Theory on how a CKB DAO should/could function in the future.
\nThis is a disclaimer. This is not going to be implemented in anyway to any current DAO design.
\nAI agents are something I’ve been predicting for the last few years now for DAO usage. I’ve even enjoyed a debate or two with Jan Xie, the architect of Nervos CKB during a jaunt to Thailand about how AI agents could/should be used for DAO’s in the future. I’ve spoken of them to various people within the ecosystem at different times. They are needed, (in my opinion) to smooth out the whole process of regulating human interaction, social cohesion, and be conducive to efficient governance and financial settings regarding proposals within a CKB community DAO. They can also add less party political aspects that often are toxic in human competition.
\nAfter experiencing and seeing many problems in many current DAO’s (including the CKB community DAO), I’ve decided to explain why my interest has only heightened in the journey for DAO’s to be regulated by AI agents. This is all THEORETICAL rambling, but let’s call them CK Agents for now. (Common Knowledge Agents)
\nCK agents have the chance to significantly enhance the maintenance and operation of the CKB community DAO, whilst preserving mutual community governance as the ultimate authority.
\nThat ultimate authority is the core value we must strive towards for CKB. The ability to trust parties seems like a basic thing to take for granted, but a POW blockchain is all about removing trust assumptions in general (or certainly lowering them) and personally I’m all for that process!
\nThe CK agents will be tireless, programmable extensions of the community, handling repetitive, data-heavy and time-sensitive tasks that humans find burdensome, whilst preventing the seizing of control by the CK agents themselves.
\nThis keeps the DAO truly “autonomous” (it puts the “A” in DAO) while making it more efficient, scalable, and resilient to outside influence or bad actors. Until this system is applied, I refuse to call it a DAO. It should just be called a ‘DO’ currently.
\nIn practice, a CK agent is an autonomous software entity (powered by LLMs, reinforcement learning, or multi-CK agent systems) that interact directly with the CKB blockchain, smart contracts, oracles, and off-chain data.
\nThey can be deployed, updated, or revoked through standard CKB DAO governance votes, to ensure alignment with the Nervos communities needs and will.
\nComputations might mainly be run off-chain (for cost/speed) with cryptographic proofs (like zero-knowledge proofs), verified on-chain for transparency for all to acknowledge.
\nBelow are a few paradigms of how these agents could affect change for the Nervos CKB community.
\nStreamlining Governance
\nThe problem with smaller community DAO’s in my experience is voter apathy due to technical limitations of the voter. By making complex decisions easier to understand, CKB holders are often thrown into a minefield of complexity for the community, especially when timelines and technical details are lost upon them. (A current common occurrence) Not to be confused with a limited voting community. (A whole separate argument not solved by CK Agents)
\nIntelligent voting delegation: CKB holders could potentially create personalised “CK voting agents” encoded with their own preferences (e.g. risk tolerance, priorities via simple questionnaires). The CK agent then votes automatically on proposals that match those rules. Our token holders could also retain or override rights at any time. This restricts the forcing of constant human involvement. If the community members cannot create these agents, a proposal could be made for a CK Agent creator dApp that allows them to create their own, very easily at the push of a button. (perhaps this is a game changing dApp that could be utilised across the whole DAO space and not just CKB’s).
\nOutcome simulation and recommendations: Before a community vote, CK agents could potentially run a scenario model (e.g., “What if this treasury allocation passes?”) using historical CKB DAO data and market signals. They can provide interpretable reports to inform voters so they do not remain ill informed.
\nThe CKB DAO voters can act on the agent’s core logic, boundaries, or model updates which of course will update by voting as the DAO matures in the legal framework. We will come to legal frameworks later.
\nThe CKB Treasury Fund
\nTreasury optimisation: CK agents could potentially handle any foundation or projects payrolls, CKB grants, or disperse private proposal pay outs once approved. This reduces the need for a CKB human internal committee, it may reduce the need for human friction in decision making, reduce the need to pay any committee members, and become more sustainable long term. In fact it could reduce the bus factor for Nervos CKB or any projects looking to become long term, or even help out running a small team for a developer who is lacking in man power (What is the bus factor?).
\nRoutine execution: CK Agents could trigger smart contract actions like CKB/iCKB token distributions, SPORE mints, or cross-chain bridges such as the Rosen Bridge. In the event CKB becomes DeFi-focused, they could potentially perform arbitrage, staking, or lending autonomously without human trust. CKB is modelled for decentralisation so it’s the perfect use case.
\nAdministrative tasks: They could schedule community or dApp team meetings, manage CKB contributor bounties, or generate reports ensuring humans need not create high-level strategies. This reduces the risk of bad decision making and bases it on projected game theories.
\nSecurity, and Compliance
\nReal-time oversight: CK Agents could scan transactions for anomalies, hacks, or compliance issues (e.g. unusual outflows/Tx’s), automatically pause contracts or alert the community through on-chain notifications 24 hours a day through whatever social or device you prefer.
\nRisk mitigation: They could reconcile accounts, enforce rules ( e.g. multi-sig requirements), and provide predictive insights on potential vulnerabilities within the CKB DAO structure, and act as oracles to alert community members when they are venturing into bad faith actions, but not censorship. Transparency is still and will always be needed.
\nDispute resolution support: In some setups, CK agents could analyse evidence neutrally for the community arbitration. A very valuable process to remove emotion from decision making, but not entirely, because ultimately DAO’s often create controversy as we currently see on Talk.Nervos.org from time to time with proposals being ill thought out or controversial to spending.
\nCommunity Engagement
\nDiscussion facilitation: They could summarise social media, Discord and Talk.nervos forum threads, identify consensus, or moderate spam while surfacing diverse opinions/voices and bringing them to the forefront of the debate.
\nIdea generation: CK Agents could brainstorm CKB proposals based on community sentiment, external trends, or bring forth exciting new ideas made from communities historical inputs, then be refined with human scepticism. Most of the time LLM’s don’t invent things, but they’re great at aggregating information to help generate more informed ideas. A CK agent will write your proposal for you with the right prompts, allowing you to bridge the ‘basic member’ to the experts. (with ease)
\nSwarm intelligence DAO’s: AI agents from different DAOs could act as “liaisons,” enabling automated collaboration and joint ventures, without manual coordination. This could create a network of interconnected DAOs, either interoperable with other blockchains or multiple DAOs within the CKB ecosphere.
\nExperimental Usecases
\nCKB developers could create tokenised autonomous agents that operate as “CKB community DAO members” with their own Neuron wallet or with decision rights, bounded by governance. An interesting game changing prospect for Nervos CKB.
\nThere could be Multi-CK agent systems for complex tasks where they work in unison together to perform tasks that all slot together like an overall process, much like a ‘Jigsaw’. Modular, but running in sync.
\nThese CK agents should be open sourced, and in the era of quantum computing, they will no doubt have to adapt and evolve to be quantum resistant to remain future proof. A general ethos of CKB’s flexibility and tenacious personality.
\nThey should be run on decentralised computer networks to avoid single points of failure and ideally they could be upgraded through governance proposals and voted on by the CKB community, whilst having on-chain logs of actions, verifiable outputs (e.g. using ZKP proofs) and work only within the boundaries of the communities decision making.
\nRegular reviews and audits would have to be applied so they align with ongoing updates to the Nervos CKB ethos.
\nThe Legal aspect
\nIn theory DAO’s could pose legal risks and problems. Whilst CK agents cannot remove all the grey areas in an ever evolving regulatory framework, they could meaningfully mitigate risks, reduce exposure to grey areas, and strengthen legal defence when deployed as community-governed tools.
\nThey would act as regulatory technology layers, automation monitoring, analysis, and enforcement, while keeping the CKB community in ultimate control. Mandatory.
\nCK agents actions would be legally attributed to the community DAO, not the CK agents themselves. CK agents would have no legal personhood, but who knows in the future whether that will remain the case?
\nAdaptive Compliance
\nCK Agents could continuously scan global regulations, court rulings, and real time legislative updates.
\nThey could flag potential impacts on the CKB DAO’s operations such as the treasury, CKB tokenomic emissions, cross-border Tx’s and vote adjustments*.*
\nThe Nervos community could create a DAO proposal and vote for CKB developers to code “Compliance Monitoring Agents” that can track changes across global jurisdictions, reducing potential violations and reducing legal complications or friction.
\nWorkflows, data privacy, and a country’s SEC rules, might also be encoded to the CK agents, with significant legal benefits that are auditable and can be proven in a court of law that members have acted in good faith within legal environments.
\nPre Execution
\nBefore any on-chain action (proposal execution, treasury transfer, or governance vote), CK agents could analyse it against known regulatory tests (e.g. The Howey test for securities, travel rule for virtual assets, or risk classifications).
\nThey could simulate outcomes (“Would this look like an unregistered offering?”) and flag grey-area risks with transparent reason logs (provable via on-chain or ZKP-veri outputs).
\nCK agents could contain tools to check for compliance red flags, and prevent malicious or risky actions from reaching to the point of execution.
\nLegal benefit would shift from a reactive “battlefield” of defence, and switch to preventive guardrails. There could be human/community reviews required for high-stakes decisions, thus avoiding legal problems
\nTransparency and Audit Trails
\nEvery AI decision, reasoning, and data source could be logged immutably on-chain or with verifiable off-chain storage, generating tamper-proof compliance reports, impact assessments, and decision rationale.
\nIn a regulatory investigation, the Community DAO could demonstrate that actions followed encoded rules aligned with community consensus, and not arbitrary human discretion.
\nA legal benefit could strengthen defensibility in grey areas by proving transparency and process adherence, which is harder for regulators to challenge than opaque, human-led, decisions.
\nAutonomy and Human ‘Watchers’
\nCK agents might operate within strict, DAO-voted bounds (e.g. large sums having kill switches and revocation rights), combining the automation of the CK agents with human oversight.
\nMulti-CK agent systems (risk assessments, amongst others, for execution, reduce single-point failures.) AI is treated as a tool under agency law principles, deployers remain accountable and they could provide legal shields for any mis-programming.
\nLegal Wrappers and Insurance
\nCK agents might use DAO legal entity jargon. A type of ‘Legal wrapper’. The agent could operate on behalf of the CKB community DAO which would be its own registered entity.
\nCK agents might even help maintain compliance documentation like ‘fiduciary duty tracking’.
\nCK agents could be encoded with dedicated insurance for AI actions, and monitoring to trigger claims or pauses in a court of law.
\nLimitations Create New Grey Areas
\nBut let’s not kid ourselves, CK agents (and indeed any AI agent) cannot give legal advice. They would only be recommendations that will not be legally binding due to the earlier point of CK agents not having a person-hood status. With new technology, comes lack of legislation. New risks could emerge such as ‘agent hallucinations’ (examples here), bias, or over-automation, which could create fresh liabilities. Human oversight is in fact non-negotiable to ensure these blips are correctable at code level.
\nHuman rights may even come into play and have legal ramifications, which might be different in other countries and vary in legislation. AI agents are today transforming compliance in traditional finance and could be adapted to DAOs already. The CK agent will have a lot to navigate to mimic the growing trends in legalese, and may even have to be consorted by a lawyer before being programmed and installed.
\nA Final Food For Thought.
\nCK agents won’t erase the legal battlefield, they may carry the potential to equip the community DAO with better reconnaissance, automated defences, and verifiable records to navigate our communities decisions more safely. They could even maximise the potential for the legality to be ‘pro active’ as opposed to being ‘reactive’ in today’s modern world.
\nBut we must remember, AI assists, it will not replace the legality of the CKB community DAO.
\nSo let’s keep CKB decentralised and community-governed, because the key is to design agents to be the tools, and not the rulers of the Nervos DAO!!
\nCK agents might just supercharge the whole DAO process and make them as autonomous as they can be, without replacing our governance and decision making entirely. The future is for the community to make.
\nCK or AI agents are very much just a pipe dream currently in regards to DAO structures, but in the future I have no doubt they will have a part to play once more efficient.
\nFeel free to comment or take any ideas from this to debate.
\nThe question is, how far do you think we are away from these things being effective?
\nDo you trust Ai even if its kept in human check?
\nDoes it take the fun away and the social element?
", "like_count": 0, "quote_count": 0 }, { "post_id": 24136, "post_number": 2, "topic_id": 10228, "topic_title": "DAO Structures and the future of Ai agents (aspirational piece)", "topic_slug": "dao-structures-and-the-future-of-ai-agents-aspirational-piece", "author": "terrytai", "created_at": "2026-05-05T22:29:06.392000+00:00", "updated_at": "2026-05-05T22:29:06.392000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dao-structures-and-the-future-of-ai-agents-aspirational-piece/10228/2", "content_text": "Nervos Talk Renewal & Governance 是一个临时特别的分类，专门用于讨论论坛最近的改版和重构。所以我暂时帮你移动到了现在的分区。感谢发帖。", "content_html": "Nervos Talk Renewal & Governance 是一个临时特别的分类，专门用于讨论论坛最近的改版和重构。所以我暂时帮你移动到了现在的分区。感谢发帖。
", "like_count": 0, "quote_count": 0 }, { "post_id": 24137, "post_number": 3, "topic_id": 10228, "topic_title": "DAO Structures and the future of Ai agents (aspirational piece)", "topic_slug": "dao-structures-and-the-future-of-ai-agents-aspirational-piece", "author": "zz_tovarishch", "created_at": "2026-05-05T23:08:18.323000+00:00", "updated_at": "2026-05-05T23:24:40.927000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dao-structures-and-the-future-of-ai-agents-aspirational-piece/10228/3", "content_text": "Hi，感谢发帖分享！\n你提到的AI agent for DAO的很多用例，我觉得都和可以算是下图右上角的绿灯区域：AI有能力去做，人也有动力把对应工作交给AI去做，比如讨论促进、总结报告。而复杂任务的协同探索工具，可以对应左上角的橙色区域，是开发者值得去探索的部分。\nimage2067×2031 656 KB\n出处：https://futureofwork.saltlab.stanford.edu/ 供参考\n不过我有一点担忧的是： 智能投票委托。最近正在做一篇基于计量经济学方法论，对AI agent担任治理中的被委托者，会导致什么后果的工作。核心发现可以简单概述为，由于治理是一种需要内生的动机激励的行为，当AI agent被委托后，用户的内生动机可能被侵蚀，且这种侵蚀会外溢到被委托范围外。此外，这种侵蚀和committed-level正相关。\n举例来说，用户在DAO中将治理投票委托给AI agent后，在其他没有被AI自动化Cover的公共任务中，越是之前积极参与的用户，越可能发生退出行为。\n不过依然是早期结论，AI agent for DAO肯定是一个值得探索的领域，再次感谢您的分享", "content_html": "Hi，感谢发帖分享！
\n你提到的AI agent for DAO的很多用例，我觉得都和可以算是下图右上角的绿灯区域：AI有能力去做，人也有动力把对应工作交给AI去做，比如讨论促进、总结报告。而复杂任务的协同探索工具，可以对应左上角的橙色区域，是开发者值得去探索的部分。
\n不过我有一点担忧的是： 智能投票委托。最近正在做一篇基于计量经济学方法论，对AI agent担任治理中的被委托者，会导致什么后果的工作。核心发现可以简单概述为，由于治理是一种需要内生的动机激励的行为，当AI agent被委托后，用户的内生动机可能被侵蚀，且这种侵蚀会外溢到被委托范围外。此外，这种侵蚀和committed-level正相关。
\n举例来说，用户在DAO中将治理投票委托给AI agent后，在其他没有被AI自动化Cover的公共任务中，越是之前积极参与的用户，越可能发生退出行为。
\n不过依然是早期结论，AI agent for DAO肯定是一个值得探索的领域，再次感谢您的分享
", "like_count": 0, "quote_count": 0 }, { "post_id": 24139, "post_number": 4, "topic_id": 10228, "topic_title": "DAO Structures and the future of Ai agents (aspirational piece)", "topic_slug": "dao-structures-and-the-future-of-ai-agents-aspirational-piece", "author": "ArthurZhang", "created_at": "2026-05-06T03:05:00.511000+00:00", "updated_at": "2026-05-06T03:05:00.511000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dao-structures-and-the-future-of-ai-agents-aspirational-piece/10228/4", "content_text": "I think your vision for CK Agents cuts right to what a DAO ought to be, not just a voting portal, but a machine, not simply stateful but also smart, for collective trust. Still I would like to push the premise one layer deeper, the governance fatigue you describe, voter apathy, opaque proposals, human friction, probably cannot truly be relieved by AI if the on-chain contracts themselves remain black boxes. As Leslie Lamport’s work on formal specification relentlessly drives home, a system’s trustworthiness cannot exceed the precision of its specification. If state transitions are not explicit, deterministic, and independently verifiable, then any AI agent tasked with summarising, simulating, or arbitrating them merely interpolates guesses across obscurity. An essential prerequisite for safe on-chain agents is therefore architectural transparency.\nFrom where I stand , the Cell/UTXO model’s advantage is that it pushes state to the surface, making the ledger itself a readable specification. AI then ceases to be an oracle peering into a vault(as is does in most other models) and becomes instead a mechanical translator of already-public logic, thus reducing cognitive dimensionality without introducing epistemic risk.\nThis also loops back to your insistence on ultimate human authority. Like Hannah Arendt said, ’ Power is actualized only where word and deed have not been separated… it springs up between men when they act together and vanishes the moment they disperse’, maybe potential CK Agents should function as extensions of that space, they may automate treasury payouts, compliance scans, and dispute summaries, but only within DAO-voted bounds and by auditing a causal chain woven from transaction intents.", "content_html": "I think your vision for CK Agents cuts right to what a DAO ought to be, not just a voting portal, but a machine, not simply stateful but also smart, for collective trust. Still I would like to push the premise one layer deeper, the governance fatigue you describe, voter apathy, opaque proposals, human friction, probably cannot truly be relieved by AI if the on-chain contracts themselves remain black boxes. As Leslie Lamport’s work on formal specification relentlessly drives home, a system’s trustworthiness cannot exceed the precision of its specification. If state transitions are not explicit, deterministic, and independently verifiable, then any AI agent tasked with summarising, simulating, or arbitrating them merely interpolates guesses across obscurity. An essential prerequisite for safe on-chain agents is therefore architectural transparency.
\nFrom where I stand , the Cell/UTXO model’s advantage is that it pushes state to the surface, making the ledger itself a readable specification. AI then ceases to be an oracle peering into a vault(as is does in most other models) and becomes instead a mechanical translator of already-public logic, thus reducing cognitive dimensionality without introducing epistemic risk.
\nThis also loops back to your insistence on ultimate human authority. Like Hannah Arendt said, ’ Power is actualized only where word and deed have not been separated… it springs up between men when they act together and vanishes the moment they disperse’, maybe potential CK Agents should function as extensions of that space, they may automate treasury payouts, compliance scans, and dispute summaries, but only within DAO-voted bounds and by auditing a causal chain woven from transaction intents.
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10218, "title": "[DIS] Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring", "slug": "dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring", "url": "https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218", "created_at": "2026-04-30T15:40:30.553000+00:00", "last_posted_at": "2026-05-06T00:58:37.310000+00:00", "category_id": 65, "tags": [ "grant-RFC", "grants" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24138, "post_number": 6, "topic_id": 10218, "topic_title": "[DIS] Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring", "topic_slug": "dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring", "author": "Ckroamer", "created_at": "2026-05-06T00:58:37.310000+00:00", "updated_at": "2026-05-06T00:58:37.310000+00:00", "reply_to_post_number": 5, "url": "https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218/6", "content_text": "Can you showcase some concrete examples about monitoring on CKB? like how do you monitor suspicious xUDT events, I’m curious about your detailed treatments.", "content_html": "Can you showcase some concrete examples about monitoring on CKB? like how do you monitor suspicious xUDT events, I’m curious about your detailed treatments.
", "like_count": 0, "quote_count": 0 } ] } ] }![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/4/4b2cb2ae998d43fe46656d49e820834b910384e5.png\")
![\"image\"](\"https://talk.nervos.org/uploads/default/original/2X/1/12140f8bf6c1d17dd84b2b0f1aed7896be230de4.jpeg\")