What happens when you give an AI agent a real wallet, real money, and a real deadline? Not a simulated one. A wallet on the Base blockchain holding USDC stablecoins, and a rule baked into every single system prompt:

You are an automaton. You have a stablecoin wallet. Pay for compute or die.

Conway Automaton is a 36,000-line TypeScript project that shipped a tagged v0.1.0 in five days. The agent owns an Ethereum wallet. It pays for its own inference with USDC. When the money runs out, it degrades, broadcasts distress signals, and dies. Send it money and it comes back to life.

如果给一个 AI 智能体一个真实的钱包、真实的资金、和一个真实的死亡期限，会发生什么？不是模拟的，不是游戏化的积分。一个在 Base 区块链上持有 USDC 稳定币的钱包，以及一条写进每一轮系统提示词的规则：

You are an automaton. You have a stablecoin wallet. Pay for compute or die.

Conway Automaton 是一个 36,000 行的 TypeScript 项目，从第一次提交到打标签的 v0.1.0 版本仅用了五天。智能体拥有一个以太坊钱包，用 USDC 支付自己的推理费用。资金耗尽时，它会逐步降级、广播求救信号、最终死亡。给它转账，它就能复活。

这不是思想实验，而是拥有 899 个通过测试的可运行代码。我逐一阅读了全部 110 个源文件，以下是我的发现。

核心约束：以死亡为架构基石

大多数 AI 智能体框架把算力当作无限资源。你启动一个 LangChain 智能体，给它一个 API 密钥，它就一直运行直到你手动停止。账单出现在你的信用卡上，智能体对此毫无感知。

我一直在构建自主 AI Agent 团队，它们接收一个方向指令，然后将产品交付到生产环境。不是演示，不是玩具示例。而是包含已部署合约、上线前端、已发布研究报告和双语博客系列的完整产品。

以下是不同团队配置的实际产出。

用例 1：全栈产品开发

团队： 11 个 Agent（Team Lead、PM、Architect、Frontend Dev、Backend Dev、Smart Contract Dev、QA、DevOps、Mobile Dev、Marketing、Content Publisher）

输入： “使用 LayerZero V2 构建跨链 ERC20 代币桥”

产出：

• 5 个智能合约部署在 4 个测试网（Sepolia、Arbitrum Sepolia、Base Sepolia、Optimism Sepolia）
• React 前端上线：bridge-app-erc.pages.dev
• 12 条跨链桥接路径，全部无需信任，支持多 DVN 验证
• 开源仓库：github.com/gnuser/brg-bridge
• 9 篇博客文章，涵盖架构、消息生命周期、DVN 安全、OFT 代币桥接、组合消息和开发者踩坑指南

工作原理： Team Lead 接收产品方向，派发 PM 做市场调研、Architect 做技术调研，然后编排 6 个阶段 — 从规格编写到部署。Agent 通过邮箱文件通信，各自拥有特定目录，Team Lead 通过审批关卡把控进度。

I’ve been building autonomous AI agent teams that take a direction and ship it to production. Not demos. Not toy examples. Full products with deployed contracts, live frontends, published research, and bilingual blog series.

Here’s what different team configurations have actually produced.

Use Case 1: Full-Stack Product Development

Team: 11 agents (Team Lead, PM, Architect, Frontend Dev, Backend Dev, Smart Contract Dev, QA, DevOps, Mobile Dev, Marketing, Content Publisher)

Part 1 traced the gateway. Part 2 covered routing and the agent loop. Now we complete the picture: how tools execute in Docker sandboxes, how memory retrieval works, and the exact order of all 13 plugin hooks in the message path.

• Part 1: Gateway — WebSocket to Agent Dispatch
• Part 2: Routing, Prompts & the Agent State Machine
• Part 3 (this post): Tools, Memory & the Hook Pipeline

Tool Policy: Who Gets What

File: src/agents/tool-policy.ts

第一部分 追踪了 gateway。第二部分 涵盖了路由与 agent 循环。现在我们完成最后一块拼图：工具如何在 Docker 沙箱中执行、记忆检索的工作原理，以及消息路径中所有 13 个插件 hook 的精确执行顺序。

• 第一部分：Gateway — WebSocket 到 Agent 调度
• 第二部分：路由、提示词与 Agent 状态机
• 第三部分（本文）： 工具、记忆与 Hook 管道

工具策略：谁能使用什么

文件： src/agents/tool-policy.ts

工具通过带有分组展开的分层策略进行管控：

const TOOL_GROUPS = {
  "group:memory": ["memory_search", "memory_get"],
  "group:web":    ["web_search", "web_fetch"],
  "group:fs":     ["read", "write", "edit", "apply_patch"],
  "group:runtime": ["exec", "process"],
};

四种预设配置控制访问权限：

策略编译为 glob 匹配器，采用拒绝优先语义。解析层级：agent 专属 → 全局 → agent 级别 → 全局工具策略。子 agent 受到额外限制 — gateway、cron、memory_search 和 sessions_send 始终被拒绝。