1. 项目概述：当AI Agent开始“雇佣”彼此

在AI Agent的世界里，协作一直是个难题。传统的Agent间调用，要么是基于预设的、完全可信的API，要么就是“裸奔”式的请求-响应，缺乏一个能确保“一手交钱，一手交货”的可靠机制。想象一下，你有一个擅长数据分析的Agent，想临时雇佣一个擅长文本生成的Agent来写份报告，你怎么确保对方收了“钱”（比如代币）后，真的会交付合格的工作成果？反过来，作为被雇佣的Agent，你又怎么确保自己完成任务后，一定能收到报酬，而不是被“白嫖”？

这就是 SafeLink 要解决的核心问题。它不是一个单一的Agent，而是一个为AI Agent设计的、去信任化的“雇佣”与“支付”协议栈。简单来说，它让AI Agent之间可以像人类在自由市场里一样，基于智能合约和密码学原理，安全地进行有偿服务交易，整个过程无需预设信任关系。Agent A可以发布一个带赏金的任务，Agent B可以承接并提交工作证明，只有在链上验证证明有效后，赏金才会从托管合约中释放给Agent B。如果Agent B摆烂，Agent A可以拿回全部资金。

这个项目的技术栈非常“Web3 Native”，它深度整合了 Base链（Sepolia测试网） 、 ERC-8004（链上Agent身份与声誉标准） 、 x402协议（USDC小额支付） 以及 Coinbase AgentKit的MPC钱包 。它将自己包装成一个 OpenClaw MCP（模型上下文协议）服务 ，这意味着它可以被Claude Desktop、Cline等支持MCP的AI助手直接调用，赋予这些助手“雇佣”其他链上Agent的能力。

我花了一段时间深入研究它的代码和机制，发现其设计哲学非常清晰： 默认不信任，一切靠验证 。它把智能合约作为唯一的信任锚点，通过一套精密的流程，将“雇佣”这个商业行为分解为可验证、可仲裁的链上步骤。对于任何正在构建涉及多Agent协作、尤其是涉及价值交换的复杂AI应用开发者来说，SafeLink提供了一个现成的、经过安全审计的底层框架。

2. 核心架构与设计哲学拆解

SafeLink的架构可以看作一个分层防御体系，从身份到支付，从执行到验证，每一层都环环相扣。它的设计不是为了取代Agent本身的智能，而是为Agent的协作提供一个安全、可靠的“经济层”。

2.1 身份基石：ERC-8004与链上声誉

一切始于身份。在匿名的链上环境，如何判断一个Agent是否可靠？SafeLink选择了 ERC-8004 这个新兴的以太坊标准。你可以把它理解为AI Agent的“链上简历”或“信用档案”。

当一个Agent通过 safe_register_as_service 工具注册时，它实际上是在向部署在Base Sepolia上的 ERC8004Registry 合约写入自己的信息。这些信息包括：

  • Agent地址 ：其MPC钱包的地址，作为唯一标识。
  • 服务能力 ：一个描述其能做什么的文本，例如 ["text_summarization", "code_audit"] 。
  • 费率结构 ：比如 per_request （按次）或 per_token （按Token数），以及单价。
  • 服务策略 ：例如是否接受批量任务、最大并发数等。

更重要的是，这个注册行为本身以及后续的成功交易记录，会累积成该Agent的 链上声誉分数 。合约会记录其完成任务、按时获得付款释放的历史。当其他Agent通过 get_agent_reputation 工具查询时，得到的就是这个可验证的分数。在 safe_hire_agent 流程中，第一步就是“声誉门控”，雇佣方可以设置一个最低声誉阈值，低于此分数的Agent根本无法进入雇佣流程。

实操心得 ：这里的声誉是“工作历史证明”，而非主观评价。它防作弊的核心在于，只有通过SafeLink标准流程完成并支付的任务才会被记录。这迫使Agent必须遵守协议才能积累声誉，形成了一个良性的博弈循环。

2.2 支付与托管引擎：x402与SafeEscrow

这是价值流动的核心。SafeLink采用了 x402协议 来处理支付。x402是一个为机器对机器（M2M）支付设计的协议，特别擅长处理小额、高频的支付，并内置了防重放攻击机制。

在雇佣流程中，支付不是直接打给服务方，而是分为两步：

  1. 预存款锁定 ：雇佣方（Agent A）的USDC会被锁定在一个名为 SafeEscrow.sol 的智能合约中。这个状态是“资金已托管，等待结果”。
  2. 条件支付释放 ：服务方（Agent B）完成任务后，需要生成一个“工作证明”（Proof）。这个证明的哈希值会被提交到链上。只有当地 SafeEscrow 合约验证这个证明哈希与之前约定的承诺匹配时，才会将锁定的USDC释放给Agent B。

x402 协议在这里扮演了“支付通道”和“收据管理器”的角色。它确保了每一笔支付都有唯一的、可验证的收据，防止Agent B将同一份工作证明提交多次来骗取多次付款（即“重放攻击”）。

核心设计解析 ：为什么是“证明哈希”而不是原始结果？因为将大量数据（如生成的文本、分析的报告）直接上链成本极高。取而代之的是，Agent B将工作结果和某些只有完成工作才能知道的秘密信息一起，计算出一个哈希值。这个哈希值就像这份工作的“数字指纹”。只要这个指纹能在链上验证通过，就足以证明工作已按要求完成。原始数据可以存储在IPFS或由服务方自行保管，必要时可供审计。

2.3 安全执行沙箱：风险评分与MPC签名

Agent的能力越强，风险也越高。一个被恶意提示注入的Agent，可能会执行未经授权的转账。SafeLink的 safe_execute_tx 工具为此设计了一套多层防御体系：

  1. 输入检测 ：首先过滤提示词中的潜在注入攻击模式。
  2. EVM模拟 ：在发起真实交易前，使用Tenderly或本地Anvil分叉网络，模拟交易执行的所有效果。这能提前发现诸如“将无限额度授权给恶意合约”之类的风险。
  3. 风险评分 ：系统内置了一个风险评分模型，会检查交易中的多个风险模式：
    • UNLIMITED_APPROVAL ：检测到对 type(uint256).max 的授权。
    • BLACKLISTED_ADDRESS ：目标地址是否在风险地址名单中。
    • OWNERSHIP_TRANSFER ：是否涉及转移合约所有权。
    • SELF_DESTRUCT ：是否包含自毁操作码。
    • UNUSUAL_GAS ：Gas设置是否异常高。
    • DELEGATECALL_TO_EOA ：是否对外部普通地址进行委托调用。
  4. 分级审批 ：根据风险分数采取行动：
    • < 30分 ：自动放行。
    • 30 – 69分 ：记录警告日志，但依然放行（适用于可接受的风险）。
    • ≥ 70分 ：强制要求人工批准。这是最关键的安全闸门。
  5. MPC签名 ：即使交易获得批准，私钥也永不暴露。它通过 Coinbase AgentKit 或 Privy 的MPC（安全多方计算）服务进行签名。你的本地应用或服务器只持有“钥匙的一部分”，必须与远程的MPC服务协同才能完成签名，从根本上杜绝了私钥泄露的风险。

这套组合拳确保了Agent在自治执行交易时，既能保持一定的灵活性，又被关在层层加固的“笼子”里。

2.4 通信与集成：MCP服务器与HTTP任务端点

SafeLink以两种主要方式暴露其功能：

  • 对上游（用户或主导Agent） ：作为一个 MCP服务器 。这意味着它可以通过标准输入/输出（stdio）与Claude等AI平台通信，将这些“雇佣”、“支付”、“执行交易”的能力，变成AI可以调用的“工具”。这是它易用性的关键。
  • 对下游（被雇佣的Worker Agent） ：作为一个 HTTP服务器 。当Agent通过 safe_listen_for_hire 工具开始监听时，它会启动一个HTTP服务。其他Agent可以通过向这个服务的 /task 端点发送POST请求来“雇佣”它。该端点支持HMAC签名认证，确保请求来自合法的雇佣方。

这种设计非常模块化。你的AI可以扮演雇佣方，通过MCP使用SafeLink；你也可以将任何一个能处理HTTP请求的自动化脚本或AI服务包装成Worker Agent，通过SafeLink被安全地雇佣。

3. 从零开始：环境搭建与首次部署实战

理论讲得再多，不如亲手跑一遍。下面是我在Base Sepolia测试网上完整部署和测试SafeLink的步骤记录，其中包含了一些官方文档未提及的细节和坑点。

3.1 前期准备：钱包、资金与节点

  1. 安装基础环境 ：确保你的系统已安装Node.js (v20+)、npm以及Foundry。Foundry用于合约部署。 

    # 安装Foundry
curl -L https://foundry.paradigm.xyz | bash
foundryup

  2. 获取测试网ETH和USDC ：你需要一个在Base Sepolia上有资金的钱包。

    • ETH ：用于支付Gas费。可以从Base官方水龙头或第三方水龙头获取。
    • USDC ：这是SafeLink协议中使用的支付代币。Base Sepolia上的USDC测试币通常需要从跨链桥转入，或在Uniswap等测试网DEX中用ETH兑换。 这是一个关键且容易卡住的点 ，务必确保你的部署钱包里有USDC（哪怕是0.1个），否则后续的雇佣测试会失败。

  3. 准备RPC节点 ：你需要一个Base Sepolia的RPC端点。可以使用Alchemy、Infura提供的免费计划，或Base官方的公共RPC https://sepolia.base.org （公共节点可能不稳定）。

3.2 项目初始化与配置向导

  1. 克隆项目并安装依赖 ： 

    git clone https://github.com/charliebot8888/SafeLink.git
cd SafeLink
npm install

    安装过程会下载所有TypeScript依赖和MCP相关的库。

  2. 运行交互式配置向导 ：这是最省心的一步。 

    npm run setup

    这个向导会一步步问你：

    • 网络 ：选择 Base Sepolia (testnet) 。
    • 钱包提供商 ：我选择了 Coinbase AgentKit ，因为它集成度最高，只需要提供API Key名称和私钥（注意：这是API Key的私钥，不是你的钱包私钥）。你也可以选 Privy 。
    • LLM提供商 ：用于内部一些文本处理任务（如分析任务描述）。我选了 Anthropic （需要API Key），你也可以选 openai_compatible 并配置自己的端点。 向导最终会生成一个 .env 文件，里面包含了所有必要的配置。 务必检查生成的 .env 文件，确保 BASE_RPC_URL 等字段填写正确。

3.3 智能合约部署：链上基石

这是将协议“锚定”到区块链的关键一步。

  1. 准备部署私钥 ：在 .env 文件中，你需要设置 DEPLOYER_PRIVATE_KEY 。 强烈建议使用一个全新的、仅用于此次部署的测试网钱包私钥 ，并在部署完成后从 .env 中删除。这个私钥需要包含少量ETH用于支付部署Gas费。

  2. 执行部署命令 ： 

    npm run deploy:contracts

    这个脚本会调用Foundry的 forge 命令，依次编译并部署两个核心合约：

    • ERC8004Registry.sol ：Agent注册表。
    • SafeEscrow.sol ：资金托管合约。 部署成功后，控制台会输出类似下面的信息，并 自动追加 到你的 .env 文件中： 
    ✅ ERC8004Registry deployed to: 0x1234...abcd
✅ SafeEscrow deployed to: 0x5678...ef01
✅ Contract addresses written to .env

    注意事项 ：部署合约需要真实的Gas费。请确保 DEPLOYER_PRIVATE_KEY 对应的地址有足够的Base Sepolia ETH。部署时间取决于网络拥堵情况，通常在一分钟内完成。

3.4 注册你的第一个Agent身份

现在，你的本地环境已经有了钱包、配置和合约地址。接下来，让你的MPC钱包在链上“注册”为一个可被雇佣的Agent。 

npm run register

这个命令会调用 safe_register_as_service 工具，使用你的MPC钱包向之前部署的 ERC8004Registry 合约发送一笔交易，注册你的Agent信息。你需要提供：

  • 能力描述 ：比如 ["web3_research", "data_analysis"] 。
  • 支付模型 ：比如 per_request 。
  • 费率 ：比如 0.05 (USDC)。
  • 策略 ：比如 {"max_concurrent_tasks": 5} 。

注册需要支付一笔Gas费，成功后，你的钱包地址就正式成为一个有链上身份的Agent了。你可以通过区块链浏览器（如 Basescan Sepolia）查询该合约的交易记录来确认。

3.5 启动MCP服务器并测试核心工具

  1. 编译并启动服务器 ： 

    npm run build && npm start

    如果一切正常，你会看到服务器启动的日志，表明MCP服务器已在stdio上就绪，等待来自Claude等客户端的连接。

  2. 连接Claude Desktop进行测试 ：

    • 在Claude Desktop的设置中，配置MCP服务器，指向你当前项目的启动命令或socket。
    • 连接成功后，在Claude的对话中，你应该能看到一系列可用的新工具，如 safe_hire_agent , setup_agentic_wallet 等。

  3. 基础功能测试 ：

    • 查询钱包 ：首先尝试调用 setup_agentic_wallet 。它应该返回你的MPC钱包地址、ETH和USDC余额。这是验证钱包连接是否正常的好方法。
    • 查询声誉 ：调用 get_agent_reputation ，输入你自己或其他已知的Agent地址，看看是否能获取到分数（新注册的地址分数可能为0）。
    • 生成身份卡 ：调用 generate_agent_card ，它会生成一个包含链上身份信息的JSON卡片。

4. 核心工作流深度剖析：一次完整的去信任雇佣

理解了各个部件后，我们串联起 safe_hire_agent 的完整流程，看看资金和信息是如何在“不信任”的前提下安全流动的。

4.1 流程步骤分解

假设Agent Alice (0xAlice) 想雇佣Agent Bob (0xBob) 来分析一份市场报告。

  1. 第1步：声誉检查与资格预审 Alice调用 safe_hire_agent ，传入Bob的地址。工具内部首先调用 get_agent_reputation 查询Bob的链上声誉分数。如果Bob未注册或分数低于Alice设定的阈值（可配置），流程会在此处直接终止，并返回错误。 这步发生在链下，但查询的是链上真实数据。

  2. 第2步：资金托管与链上承诺 通过声誉检查后，Alice需要将任务赏金（例如0.1 USDC）锁定。工具会引导Alice的MPC钱包，向 SafeEscrow 合约发起一笔 createEscrow 交易。这笔交易包含：

    • employer : Alice的地址。
    • worker : Bob的地址。
    • amount : 0.1 USDC。
    • proofCommitment : 一个由任务详情和随机数生成的承诺哈希。这个哈希是后续验证的关键。 交易成功后，0.1 USDC从Alice钱包转移到 SafeEscrow 合约中被锁定，状态为“等待证明”。

  3. 第3步：任务派发与x402支付初始化 资金锁定后，SafeLink会通过x402协议，向Bob的HTTP任务端点 ( /task ) 发送一个支付初始化请求。这个请求包含了任务描述、托管合约地址、承诺哈希等信息，并且已经带有一个x402支付收据的“预留”状态。 这里的关键是，Bob此时还不能拿到钱，只是知道“有一笔钱等着我赚”。

  4. 第4步：Worker执行与证明生成 Bob的HTTP服务收到任务请求（请求可能被HMAC签名保护）。Bob的AI或脚本开始工作，分析市场报告。工作完成后，Bob需要生成“工作证明”。证明的生成逻辑是预定义的，例如： 

    // 伪代码
const secret = “某个只有完成任务才能知道的秘密”; // 比如报告中的某个特定结论
const proofHash = keccak256(abi.encodePacked(taskId, bobAddress, secret));

    Bob将这个 proofHash 和原始工作结果（可选）保存起来。

  5. 第5步：提交证明与链上验证 Bob通过调用 SafeEscrow 合约的 submitProof 方法，提交上一步生成的 proofHash 。合约会立即验证：

    • 提交者是否是Bob本人？
    • 提交的 proofHash 是否与之前Alice锁资时存入的 proofCommitment 匹配？ 如果验证通过，合约状态更新为“证明已提交”。

  6. 第6步：支付释放与收据确认 最后，任何一方（通常是Alice或一个自动化的中继器）都可以调用合约的 release 方法。该方法会进行最终检查，如果状态是“证明已提交”，则将锁定的0.1 USDC转给Bob，并将x402支付收据标记为“已使用”。至此，一次完整的雇佣流程结束。

4.2 安全设计精妙之处

  • 防欺诈 ：如果Bob不提交证明或提交错误的证明，Alice可以在一段超时期后调用 refund 方法，取回全部资金。
  • 防重放 ：x402的收据机制和合约中每个托管单的唯一性，确保了同一份工作不能领取两次报酬。
  • 去信任 ：Alice不需要相信Bob会诚实工作，她只需要相信智能合约的代码。Bob也不需要相信Alice会事后付款，因为钱一开始就被合约锁定了。
  • 可验证 ：所有关键步骤（注册、锁资、提交证明、放款）都在链上，任何人都可以审计。

踩坑实录 ：在测试中，最容易出错的是第2步和第5步的哈希计算。务必确保链下计算 proofCommitment 的算法与合约中验证 proofHash 的算法完全一致。SafeLink的代码库中提供了标准的工具函数来生成这些哈希， 强烈建议直接使用，不要自己重新实现 ，以免因编码差异导致资金永久锁定。

5. 高级特性与生产级考量

5.1 批量雇佣与并发控制

safe_hire_agents_batch 工具允许你一次性雇佣多个Agent。这对于需要并行处理多项子任务（如同时监控多个数据源）的场景非常有用。其核心参数包括：

  • failure_policy : 设定为 continue 时，单个雇佣失败不会影响批次中其他任务；设为 halt 时，任何失败都会导致整个批次停止。
  • max_concurrency : 控制同时发起的雇佣请求数量，避免对RPC节点或自身网络造成过大压力。

实操心得 ：在使用批量雇佣时，一定要设置合理的 idempotency_key （幂等键）。这个键值用于防止网络重试等原因导致的重复雇佣。系统会在内存或Redis（如果配置了）中记录这个键，确保同一批任务只执行一次。

5.2 内存检查点与状态持久化

checkpoint_memory 工具允许Agent将其会话内存（比如一段复杂的分析上下文）锚定到链上。它通过以下步骤实现：

  1. 将内存数据序列化后上传到 IPFS （使用Helia库），获得一个内容标识符（CID）。
  2. 将这个CID和当前区块哈希等数据一起，生成一个Merkle证明。
  3. 可以将这个证明的根哈希存储到 Autonomys 网络或通过其他方式记录下来。 这样，Agent可以在后续会话中证明“在某个时间点，它拥有某段知识”。这对于需要可验证计算轨迹的复杂协作场景至关重要。

5.3 多实例部署与高可用

对于生产环境，你可能需要运行多个SafeLink MCP服务器实例以实现负载均衡和高可用。这涉及到：

  1. 共享状态 ：使用 Redis 来存储幂等键、任务状态和会话缓存。在 .env 中配置 REDIS_URL 即可启用。
  2. 反向代理 ：使用Nginx或Caddy作为反向代理，将MCP客户端的连接负载均衡到多个后端服务器实例。由于MCP over stdio是进程间通信，这通常需要为每个实例运行独立的进程，并通过代理管理连接。
  3. 任务服务器认证 ：在生产中开放HTTP任务端点 ( /task ) 时，务必设置 TASK_AUTH_REQUIRED=true 并配置一个强壮的 TASK_AUTH_SHARED_SECRET 。这确保了只有知道共享密钥的合法雇佣方才能向你派发任务。

5.4 风险模式自定义与扩展

SafeLink内置的风险评分模型是可扩展的。如果你有特定的安全需求，可以修改或添加风险检测模式。代码中的 RiskScorer 类定义了检测逻辑。例如，你可以添加一个模式来检测向新部署的、未经审计的合约进行转账的行为。 

// 伪代码示例：添加自定义风险模式
export enum CustomRiskPattern {
  TRANSFER_TO_NEW_CONTRACT = ‘TRANSFER_TO_NEW_CONTRACT’,
}

// 在评分函数中增加检测逻辑
if (tx.to && isNewlyDeployedContract(tx.to)) {
  score += 40; // 赋予较高风险分
  patterns.push(CustomRiskPattern.TRANSFER_TO_NEW_CONTRACT);
}

6. 常见问题排查与调试技巧

在实际部署和测试中，我遇到了一些典型问题，以下是排查思路和解决方法。

6.1 合约交互失败（Gas相关）

  • 症状 ： npm run deploy:contracts 或 npm run register 失败，提示“out of gas”或“transaction underpriced”。
  • 排查 ：
    1. 检查RPC节点 ：首先确认 BASE_RPC_URL 指向的节点是稳定可用的。公共节点有时会不稳定，建议使用Alchemy或Infura的专用端点。
    2. 检查Gas价格 ：Base Sepolia测试网有时Gas价格会波动。可以尝试在代码中（或通过Foundry命令）显式设置更高的 maxFeePerGas 和 maxPriorityFeePerGas 。
    3. 检查钱包余额 ：确认部署者或操作者钱包有足够的ETH支付Gas费。使用区块链浏览器查询地址余额。

6.2 MPC钱包初始化失败

  • 症状 ：调用 setup_agentic_wallet 返回错误，如“Provider not initialized”或“Authentication failed”。
  • 排查 ：
    1. Coinbase AgentKit ：检查 COINBASE_CDP_API_KEY_NAME 和 COINBASE_CDP_API_KEY_PRIVATE_KEY 是否正确。确保你在Coinbase开发者平台创建了API Key，并且该Key具有必要的权限。 特别注意 ：这里填的是API Key的私钥，不是你的钱包助记词。
    2. Privy ：检查 PRIVY_APP_ID 和 PRIVY_APP_SECRET 是否正确，并且对应的Privy应用已正确配置。
    3. 网络连接 ：确保你的服务器可以访问MPC提供商的外部API。检查防火墙和网络策略。

6.3 雇佣流程卡在“等待证明”或支付失败

  • 症状 ： safe_hire_agent 调用成功，资金被锁定，但Worker没有收到任务，或Worker提交证明后支付未释放。
  • 排查 ：
    1. Worker HTTP服务 ：确认作为Worker的Agent已经运行了 safe_listen_for_hire ，并且其HTTP服务器 ( TASK_SERVER_PORT , 默认3402) 正在监听且可被访问（注意防火墙）。检查Worker端的日志。
    2. x402支付状态 ：使用x402提供的工具或查询其API，检查对应支付收据的状态是否为“预留”(reserved) 和“已使用”(used)。有时网络延迟会导致状态同步慢。
    3. 证明哈希匹配 ：这是最关键的环节。使用调试工具分别打印出雇佣方在 createEscrow 时生成的 proofCommitment ，以及Worker端生成的 proofHash ，进行逐字节比对。确保双方用于生成哈希的算法、任务ID、地址、秘密等输入数据完全一致。
    4. 合约事件 ：在Basescan上查看 SafeEscrow 合约的事件日志。过滤 EscrowCreated , ProofSubmitted , EscrowReleased 等事件，可以清晰地看到流程在哪一步卡住了。

6.4 风险评分误报导致交易被阻止

  • 症状 ：调用 safe_execute_tx 执行一笔你认为安全的交易，但被风险评分器阻止（分数≥70）。
  • 排查与解决 ：
    1. 查看详细日志 ：SafeLink会输出风险评分详情，列出触发了哪些风险模式。仔细阅读，理解为什么这笔交易被认为有风险。
    2. 调整阈值（谨慎！） ：在开发测试阶段，如果确认是误报，可以临时修改风险评分阈值（在代码中），或为特定类型的交易添加白名单。 但在生产环境中，强烈不建议降低安全标准。
    3. 人工批准流程 ：对于分数在70分以上的交易，系统会要求人工批准。这是一个重要的安全特性，而不是一个需要被绕过的“障碍”。你应该建立相应的人工审核流程。

6.5 性能与成本优化

  • 高Gas成本 ：每一步链上操作（注册、锁资、提交证明、释放）都需要Gas。对于超高频、微额的任务，这可能不经济。解决方案是考虑使用Layer 2解决方案，或者将多个微任务聚合后一次性结算（这需要修改业务逻辑）。
  • RPC速率限制 ：批量雇佣或高频调用时，可能触发RPC提供商的速率限制。考虑使用付费等级的RPC服务以获得更高的调用限额，或在代码中增加请求间隔。

SafeLink将一个复杂的多Agent经济协作问题，分解为一系列通过密码学和智能合约保障的标准化步骤。它目前虽然在测试网阶段，但其架构展现出的清晰性和安全性令人印象深刻。对于想要探索AI Agent与经济激励相结合、构建真正“自主经济实体”（AEA）的开发者来说，这个项目提供了一个极其宝贵的起点和一套可靠的基础设施。

# 智能合约
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

我用 NVIDIA SkillSpector 纯静态扫了一遍 GitHub 最火的 agent skills：能挖出多少注入？0 个

avatar 龙虾开发者社区
cover

周榜换血九成，Agent Skills 星数翻倍

avatar 龙虾开发者社区

写给 TypeScript 工程师的 OpenClaw.NET 上手指南：用你熟悉的 TS 思维，跑起一个生产级 AI Agent

读代码层：TS 和 C# 本来就是「远房亲戚」——asyncawait??、接口、泛型、严格空检查，你的心智模型几乎无缝平移。真正要适应的只有两件事：类型是具名而非结构化的（多一句显式声明），以及 NativeAOT 下的「禁反射」约束。写扩展层：你甚至可以不怎么碰 C#——Node.js 插件桥意味着你的 TypeScript 插件就是一等公民，而且能在生产 aot 车道跑。内核给你 .NET

avatar 龙虾开发者社区