市场调研工具 Owli 的落地(一)
也是，agent 长时间运转与工具间通信的实战
—— Owli 手记 · 第二页 · 落地进展记录
▣ 现 场 速 记
规划阶段我花的时间最多，但真正卡住我的问题，一个都不在规划里——低成本怎么跑、无人值守怎么不断线、网络通道被大数据撑爆怎么办。
记录 ①背景
「背景」一节开头的配图
自从 GitHub 项目立项到现在，我一直以为，打造一个不需要人工干涉的数字员工，其实就是把人当成「水管工」和「粘合胶水」：把相关的信息、工具都链接好，然后用大模型把信息处理好，再搭个看板，就差不多了。
在搭建阶段，我也确实花了很多时间在「项目规划」上：项目架构、数据流、agent 长期协作时该怎么通信、用什么 SDK 来驱动。其实也是想模仿别人——在 AI 开始写代码之前，就把相关的任务设计好，从 vibe coding 变成 verification coding。
「开始推进落地」需求文档片段之一
然后我就开始真正逐步推进项目落地，实际上也遇到了一些问题。有些确实是意料之外的事情，甚至某一个时刻，我也一筹莫展。不过有进展，所以记录成长。
记录 ②项目进展
实际效果流程图（可干预、可追溯、可自主规划调研行为并驱动工具）
在无人干预的情况下，Owli 已经能自主根据一条「调研需求」，自己制作出一份「调研计划」——包括怎么采集、采集完怎么分析，以及信息如何溯源。
围绕目前的初步用户场景「产品竞品」调研，已经接入了这些数据源工具：
✎ 已 接 入 页
· Product Hunt
· Hacker News
· 网络搜索，哈哈哈，其实就是先针对海外，我毕竟先做出海嘛
目前的目标，是把下面这三件事搭起来：
其一 数据可溯源
其二 让 agent 能明确知道，从哪里获得什么数据
其三 信息源可信度
下一个阶段是信息源扩容（接入 MediaCrawler 这类采集集成工具）、优化报告的产出效果、整体稳定性，以及自主学习能力。当然，我也不知道是不是都会做，至少 MVP 先运行起来了。
「开发收获」一节之前的配图
大型无人干预项目的开发收获
抛开时间、人工以及费用成本，我想总结一些我遇到的情况。这些情况一开始我可能没有注意到，后续却又很有意义。
记录 ③低成本下，如何开发大型 agents 协作项目
「成本」关于部分费用的截图
核 心
选择合适的 agent 框架，选择合适的模型（不是什么时候都该用最好的模型能力），在 MVP 阶段采用小范围的验证。
我个人跟 agent 协作，其实是烧不起 API 按量付费的，只能想办法薅已有的会员套餐。所以我不得不舍弃了 PI 框架，而把 Owli 这个项目变成一个「操作抓手」——让它去操作与调度现有的本地终端，再由终端里已有的 Claude、OpenAI 框架以及 App 去干活。
感觉我好像是多此一举，但没办法：Claude 已经禁止了第三方调用它套餐内的 usage，我只能如此。
✎ 补 · agents 框 架
agents 框架里有几个热门选择，像 Claude SDK、PI 等等。其中 PI 框架以简洁、干净而闻名，像 OpenClaw 这类很多有名的工具，其下的核心 agents 框架就是 PI。
实际上可以理解为：模型跟工具调用分离了——你提供 API Key 去跑模型端，然后工具再依次调用就好。
「补 · agents 框架」当前比较热门也是后续工具可能的agents框架
记录 ④无人监督下，如何确保 agent 开发长时间运转
「长时间运转」可能遇到的问题，如图
在早期，我发现一旦要在一个 Claude Code 聊天框里跑较长、较复杂的项目，就会出现 connection 这样的问题。
一开始觉得也没啥问题，后面发现已经离谱到连续好几次都这样。我不想变成一个 24 小时坚守的「监控者」，所以我就自己写了一个脚本：让脚本自动监控目前运行的所有进程，并且针对有问题的、中断的项目，进行信息通信。
在我能做到这个的时候，我觉得真的好酷。原来 Mac 电脑自带这样的信息间的通信。某种程度上这也说明，无人干预的本质，是「agents 管理学」里的agent / 脚本盯着 agent。
「确保长时间运行的方法」使用系统脚本做监听以及输入
不过，要想让项目长时间运行，还是要注意：
✎ 长 跑 检 查 页
① 确保熄屏时，Codex App 与终端都能继续正常运行
② 项目如果达到 token 限额时，该如何去办
③ 如果一个引擎出问题了，是否有备用的，或者设置 retry（心跳）机制
…
↳ emmmm，当第二天起床发现项目没有正常跑到相应的阶段，大家可以排查下我上面主要提到的，看是否有在项目设计中出现。
记录 ⑤Agent 吞吐大量数据时，会中断运行
「吞吐中断」以血管做例子
如果把咱们跟 agent 之间的对话，比喻成「咱们是心脏，通过血管去传输养料、去控制手来实现一些东西」，那其中的「血管」，就可以看作咱们本地（用户电脑）连接远程 AI 服务的网络通道——它会受咱们的网速，以及所传输的信息量影响。
令我难受的是，我使用的是代理 + 静态住宅 IP 的方式，网速也不是千兆宽带 + 有线直连。所以我经常遇到 Claude / OpenAI 终端在大段代码、数据输入输出时大概率必崩，一崩就又得重新开始。
一开始也没有很好的方法，咱们自己网络不好确实会这样。前天我差点花更多的钱去买「AI 网络加速器服务」，后面突然想到——「难道市面上那些数据项目没有这个问题？他们是没有解决吗？」于是我开始去下载别人的项目，去发掘他们的做法。
「核心解决方案」参考
核心的解决方案是：
其一 · 长报告从来不一口气写完
而是一章一章写，每写一点就立刻存盘，每章的进度都记在一个「进度清单」上。哪章失败了，重试几次不行，就先放一个「此处缺失」的占位标记，保证报告最后总能出来。
拆小 ＋ 随写随存 ＋ 记进度 ＋ 兜底。
其二 · 卡死检测 ＋ 断点续写
卡死检测：程序看起来在跑、其实卡住一小时不动，得有人发现并叫停。
断点续写：被掐断后从断的地方接着写，而不是重头来。
INDEX CARD · 划重点
① 低成本靠三件事：合适的框架、合适的模型、MVP 阶段小范围验证。
② 无人干预的本质是「agent / 脚本盯着 agent」，别自己去当那个监控者。
③ 网络撑爆不是花钱买加速器能解决的，靠拆小、随写随存、卡死检测、断点续写。
⚠ 适 用 边 界
这页记的全是个人实践，样本只有 Owli 这一个项目，而且还停在 MVP 阶段。换一套框架、换一种计费方式、换一条网络，结论可能完全不同。上面写的下一阶段计划，我也不确定是不是都会做。
NEXT PAGE · 下 一 步
说了这么多，其实也不敢说太多，毕竟是日记本格式的记录，项目也是开源的，记录的是自己平凡且普通的过程。
为自己喜欢的问题，创造并解决它，真的很开心。
