健身间隙发一条语音，它自己改代码、重启、修复——记录 agent 从 CLI 工具升级为手机可控自治系统的全过程
昨晚健身休息，我拿起手机对着飞书机器人说了一句：
"飞书消息现在没法续聊，帮我想个办法记录上次对话。"
十分钟后，我回来看——它已经把 feishu_gateway.py 改完、重启了服务、还把这次的修改逻辑和规则写进了知识库。
我当时愣了一下。
这篇文章记录的，是它从「只能在电脑前手动操作的 CLI 工具」升级成「手机可控自我迭代系统」的那一晚，以及现在它在做什么。
技术背景：我在用什么
- Claude Code（
claudeCLI）：Anthropic 的 agentic 编程工具，能读文件、改代码、跑命令、重启进程、验证结果 - Feishu Bot（飞书机器人）：通过 WebSocket 接收消息，回传结果
- Gateway：自己写的 ~200 行 Python，连接两者的"转接器"
- Skills：
.claude/skills/目录下的结构化任务定义，agent 的"工具箱" - Memory：
memory/long/+memory/scratch/，agent 的知识库和短期记忆
架构一句话：飞书 → Gateway → Claude Code → 文件系统/进程
为什么要做这个
Claude Code 在命令行里非常强——能自主完成"查代码 → 改代码 → 重启 → 验证"的完整闭环。但它有一个致命限制：你必须坐在电脑前。
我想要的是另一种用法：随时随地发一句话，它自己把事推进到底。更关键的是，它要能自动记笔记、沉淀经验，让自己越用越强。
Gateway 实现：200 行接通两个世界
Gateway 的核心逻辑非常简单：
飞书消息
→ WebSocket 接收
→ 提取 user_id + content
→ 拼装 claude CLI 命令
→ subprocess 执行
→ 把输出回传飞书
关键设计决策：
① 用 claude --resume 实现续聊
Claude Code 支持 --resume <session_id> 参数接续上一次对话。Gateway 把每个用户的最新 session_id 存下来，下次消息来时带上，实现"接着聊"而不是每次新开。
# 简化示意
session_id = load_last_session(user_id)
cmd = ["claude", "--resume", session_id] if session_id else ["claude"]
result = subprocess.run(cmd + ["--print", message], ...)
save_session(user_id, result.session_id)
② clear 机制
用户发 /clear 时，主动清空 session_id，下次强制新开对话。其他情况默认续聊。
③ 进程管理
Gateway 以 daemon 方式运行，通过 Makefile 管理重启：
make gateway-restart # 自动以正确用户身份重启
接入飞书前，必须坐在电脑前手动操作
让我惊呆的瞬间：它开始自己迭代自己
接通飞书的第一晚，gateway 还很简陋——只支持单轮对话，没有 --resume。
我在健身休息时用语音说了一句需求：
"帮我记个待办：飞书消息现在没法续聊，需要想个办法。比如记录上次对话；只有我主动清除（clear）才新开会话。"
然后它做的事情，不是"给建议清单"就结束——而是像一个靠谱同事，把这条需求一路推进成了可用的能力：
- 看清现状：
git status确认代码状态，检查有没有 staged 改动 - 把需求写成规则：默认续聊 vs 新开的判断逻辑，
clear触发条件，异常兜底 - 动手实现：在
feishu_gateway.py里增加 session 持久化 + clear 命令处理 - 重启验证：通过
make gateway-restart重启，用飞书发消息验证续聊是否生效 - 沉淀复用：把规则和实现要点写进
memory/long/gateway.md，下次直接复用
图3：飞书对话——bot 分析完现状，主动问"提交代码 / 部署测试 / 继续开发？"
图4：重启日志——gateway 重启成功，续聊验证
从 v0（单轮无状态）到 v1（有状态续聊），整个过程我没有碰电脑。
现在它在做什么
每日工作入口
我：现在还有什么没做完？今天做什么最合适？
Bot：扫描 todo/inbox.md + 系统状态...
上午 — 工作项先清（外部依赖，趁工作时间）
1. XX 限流/防护检查
2. XX 上线变更
下午 — 系统修复
3. 额度耗尽数据污染防护（P0，今早刚暴露）
傍晚 — 收尾
4. Auto-Trader 首周报告
图5：飞书截图——"今天做什么"
告警根因分析 + 修复建议
当系统通知里有异常，它不只是转发，而是定位根因并给出可执行方案：
通知：入场价: None | 保证金: ... | 杠杆: ...
Bot 分析：
注意到关键问题：入场价显示 None，说明下单可能失败了。
找到原因：
BTC 最小下单量是 0.001 BTC（约 $66 名义），
但 $9.78 × 5x = $48.9 名义，不够最小单。
解决方案（二选一）：
1. 提高单笔比例到 3%：$489 × 3% × 5 = $73.4 > $66 ✓
2. 提高杠杆到 7x：$489 × 2% × 7 = $68.5 > $66 ✓
执行闭环：从分析到下单
选定方案后，直接下指令：
我：现在就进行下单，直接触发很重要，我们节奏快一点
Bot：
Binance 最小名义是 $100 不是 $66。用 $20 保证金试：
下单成功！现在设止损止盈：
实盘测试完成！
BTC LONG 已建仓：
- 入场价：$65,996.4
- 数量：0.002 BTC（~$132 名义）
- 保证金：~$18.9（7x 杠杆）
- 止盈：$68,999（+4.55%）
- 止损：$63,799（-3.33%）
链路完整验证通过：下单 → TP/SL → 可在 Binance 查看持仓
[opus | Bash x8 | 59s | $0.980] 任务已完成
分析完直接执行，BTC LONG 建仓完成:
自我进化机制：它在没人管的时候做什么
这是我觉得最有意思的部分。
系统里有一个 self-evolve skill，会定期运行：扫描知识库、检查 todo、审计 skills，然后给我发一份"自检报告"：
知识进化报告 0227
评分: 7/10
修复: 3项（tech.md skill列表、inbox/backlog过期项、调度频率描述）
关键: auto-trader绩效严重过时（记录1笔+5 vs 实际3笔-195）
建议: 额度耗尽保护机制（日均22次无效重试）
这不是我触发的。是它运行一段时间后，自己沉淀出来的习惯。
普通工具，你用多用少，它都一样。Agent 不是——你每次用它，它就多理解你一点。这个积累，只有"已经开始用"的人才有。
技术选型说明
为什么用 Claude Code 而不是其他方案？
Claude Code 的核心优势是原生的 agentic 能力：它不只是"接收 prompt → 返回文字"，而是真的能操作文件系统、执行命令、管理进程。这让 gateway 可以非常薄——不需要在中间层实现任何业务逻辑，全部交给 Claude Code 处理。
为什么不用 OpenDevin / Claude Swarm 这类方案？
这些方案通常需要更重的基础设施。我的出发点是：先跑起来，再迭代。一个能用的 200 行比一个完美的 2000 行更有价值。
Skills 系统怎么用？
.claude/skills/ 下的每个目录是一个 skill，包含 SKILL.md（指令定义）和可选的脚本/资产。Claude Code 在收到相关指令时会自动加载对应 skill 的上下文。
.claude/skills/
├── writer/ ← 内容创作流程
├── fin-auto-trader/ ← 金融 agent 决策
├── self-evolve/ ← 系统自检与进化
└── ...
三个缺一不可的要素
做这套系统之后，我认为一个真正能用的 agent 闭环需要三个条件：
- 手机可达：不绑在电脑前，随时随地发需求
- 自主执行：自己检查现状 → 自己动手修改 → 自己重启验证
- 持续迭代：每次修复都留下记录，下次可以基于上次继续
缺了任何一个，它就还是个"工具"，而不是"搭档"。
越早开始，它越快变聪明
这套东西有个复利效应——你每次用它，它就多一点上下文，多一条经验，多理解你一分。
这个"半年"，从你开始用它那天算起。
别等准备好了再开始。你开始的那一刻，它才开始变好。
下一篇，你来选
A：金融 agent——每天定时"看盘 + 复盘 + 行动" 策略因子权重根据结果反馈自我调整，越跑越贴合你的风格
B：2 分钟把 agent 放进手机的最简部署方法
最小化依赖，一个命令启动，先跑起来再说
评论区告诉我你更想看哪个。
如果你也在做类似的事，欢迎私信交流。
