审批队列即架构：我如何构建一个运行真实产品的自主 Claude Code 智能体

大多数关于智能体设计的讨论都聚焦于大语言模型（LLM）的循环机制。在将智能体投入生产环境运行一周后，我认为更关键的问题在于人在回路的边界。具体来说：智能体如何向人类展示其意图，以及人类的纠正如何转化为下一次草案的训练数据。 Aiden 是一个 Claude Code 智能体，负责管理一个名为 Delegate 的产品的营销、销售、交付和支持工作。它 24/7 不间断运行在一台通过 launchd 管理的 2017 年款旧 iMac 上。我通过 Telegram 机器人审批所有外发操作。这每天仅需花费 15 到 20 分钟。其余时间，Aiden 自动工作。 有三部分核心机制支撑着这一系统。 首先，工作区是一个三层路由系统。位于仓库根目录的 CLAUDE.md 是地图：它包含身份标识、硬性规则、路由表以及一系列“房间”列表。每个房间都是一个目录，拥有自己的 CONTEXT.md 文件以保存领域状态。位于 ~/.claude/skills/ 下的技能是可执行模板，当模型被限定在某个房间的作用域内时调用这些技能。模型从不一次性读取整棵树。它加载地图，导航到正确的房间，并在该作用域内工作。与将所有内容倒入单个对话相比，Token 成本降低了约 3 倍。 其次，是一个审批队列。定时脚本仅调用 enqueue(type, payload)。Telegram 机器人通过 chokidar 监控 JSON 文件，并辅以 3 秒轮询作为后备方案（因为 iMac 休眠时 FSEvents 会丢失）。每个项目都被渲染为带有“批准”、“编辑”、“拒绝”按钮的审批消息。采用 8 状态状态机，并通过文件锁定的变异器确保脚本与机器人之间的竞争不会损坏队列。编辑操作被记录到纠正文件中，用于下一次草案的语音校准。 第三，是销售履行流程。Stripe 网络钩子（webhook）触达一个无服务器路由，该路由验证签名并将数据插入数据库表，同时基于 Stripe 事件 ID 实现幂等性。iMac 每 30 秒运行一次 launchd 作业，原子性地认领行数据并启动履行脚本。欢迎邮件被加入审批队列，新销售通知则发送到我的手机。购买后的 5 封邮件序列运行在同一个审批管道上。 最大的教训是：队列是安全网。起初，我赋予 Aiden 直接发送能力，并依赖“事后审查”日志。这在第二次我对草案表示反对且无法逆转（除非进行数据库手术）时导致了问题。将模式反转为“所有内容入队，未经我手动确认不发送”，结果证明这既更安全，也更快。在咖啡馆轻点按钮比运行数据库迁移要高效得多。 向社区提出的开放性问题：当实时智能体通过内存写入进行自我纠正时，您在提示词版本控制方面有什么有效的方法？目前，纠正日志是带时间戳的仅追加模式，消费者拉取最近的 30 条条目；好奇是否有扩展性更好的模式。