GitHub Actions 每日自动测试:从 schedule 踩坑到跑通
我在维护两个项目,一个是 Swift 写的 macOS CLI 工具(ForgeLoop),另一个是 Rust 写的微信 Bot(AMClaw)。开发阶段每次 push 都跑全量测试太费时间,而且有些测试在本地 commit 之前已经跑过了,CI 再跑一次完全重复。
我在维护两个项目,一个是 Swift 写的 macOS CLI 工具(ForgeLoop),另一个是 Rust 写的微信 Bot(AMClaw)。开发阶段每次 push 都跑全量测试太费时间,而且有些测试在本地 commit 之前已经跑过了,CI 再跑一次完全重复。
在 iOS 开发里,没有哪个基础控件能像 UITextField 这样—-表面上代码只有一行,背地里却牵扯到半个操作系统的子模块。它泄漏、它卡顿、它生命周期诡异、它让内存检测工具集体失语。更麻烦的是,这些问题往往不是你代码写错了,而是系统层面组合出的结果。
把 Agent 的上下文理解成“聊天记录”,很自然,也很容易把问题看浅。
我最早把 Thought 看得很重。
前两篇写 Planning 和 ReAct 的时候,我其实一直没把问题说到底。
我最早搭 Planning 模式的时候,觉得它比 ReAct 优雅很多。先花一点时间把任务想清楚,拆成步骤,排好依赖,再一条条往下走。不像 ReAct 那样边想边做,每一步都临场拍脑袋。Planning 看起来更有条理,也更可控。
我最早接触 ReAct 的时候,对它的理解很简单。模型先想一下,再调一个工具,拿到结果以后继续往下走。这个循环本身不复杂,真正难的地方,看起来也很明确:提示词怎么写,工具描述怎么给,示例要不要补,输出格式怎么约束。