AI秘书系统+AI学习系统再升级:我离 Agent Team 又近了一步

新闻

作者：微信文章

这几个月，我开始把零散的 AI 能力真正串起来

今年 1 月 18 日，我写过一篇文章，叫《我搭了AI秘书系统，提前感受OpenAI的终极产品形态》。

那时候，我其实已经开始提前感受到一点 OpenClaw 这类产品的形态了，某几个环节已经能交给 AI，很多输入输出也开始往同一个系统里汇，统一交互入口。

但现在回头看，那一版还只是局部自动化，于是接下来的这两个月，我开始继续迭代。

补 skill，补脚本，补流程，让原来零散的能力开始被串起来，慢慢从几个孤立节点，走向一条真正能跑的链路。

迭代的过程我慢慢发现，这次升级真正想搞清楚的，是在人机协作里，到底哪些事该我做，哪些事该交给 AI。


重新定义人机交互

以前我和 AI 的关系，更像是我主导整条流程，AI 在某几个节点上给我打补丁。

我去找资料，我去整理任务，我去判断下一步该怎么推进，AI 负责总结一段内容，改一段文字，或者帮我完成一个局部动作。

这样的用法当然也有价值，但本质上还是人拖着 AI 走。

说到底，那时跑起来的还是局部自动化，还谈不上完整协同。

这两个月随着 skill 越来越多、流程越来越稳定，自动化程度也开始往前走了一步，开始慢慢变成Agent。

Agent代替部分人，是必然的。但我越来越清楚，应该思考人和 AI 的边界到底该怎么划。

有些事情天然就该交给 AI。比如记录、抓取、整理、归档、回写、分发、初步执行，这些事情基础、繁琐、重复，而且很消耗注意力。

它们本来就不应该继续占着我大量的时间。

而人真正该保留注意力的部分，其实没有变。

目标怎么定，优先级怎么排，哪些事情值得做，哪些结果可以接受，系统有没有偏离方向，最后由谁来拍板和承担结果，这些事仍然必须由人来做。

所以我现在越来越认同一句话：AI 负责 dirty work，我负责判断。


我的日常，正在被两个Agent接管

现在我的两个 Agent 已经开始稳定跑起来了。

第一条是生活管理流，也就是 AI 秘书 Agent。

生活里的各种输入先进入系统，再被分成记录、待办、日程、关系推进这些不同类型，然后通过每天和每周的复盘重新整理。

这套东西的重点不在记更多。

它要做的，是把这些碎事重新放回秩序里。

哪些该推进，哪些该延后，最近有没有偏离长期目标，都会在这个过程中慢慢被看清。

在这条流里，AI 是一个执行系统。它负责接住记录、整理、回写、更新这些基础动作。

我真正要做的，是看方向有没有跑偏，哪些事情值得继续投入，哪些地方需要重新校准。



第二条是信息处理流，也就是 AI 学习 Agent。

网页、YouTube、播客、PDF、Markdown、RSS 这些外部信息，先被采集进来，再被整理、结构化、筛选和沉淀。

接下来，一部分内容会进入 AI 日报和 AI 周报，一部分会进入知识库，一部分会继续变成公众号素材，另一部分则会流到副业的二级市场投研里。

这条流的价值，是让信息真的变成资产。

收藏和摘要都只是中间环节。

最后这些东西要么变成文章，要么变成知识卡片，要么变成研究判断。



这两条流加在一起，接住的其实就是我的日常。一条管生活和执行，一条管信息和认知。

越来越多的执行环节已经可以稳定交给 AI，但每到目标、取舍、校准这些地方，我还是得自己站出来。
Agent 是一串相关联的 skill

这也是我这轮升级里一个很重要的变化。

我现在理解的 Agent，更像一条执行链。

前面有输入，中间有分流、有处理、有回写，后面有结果沉淀。

把这条链真正串起来的，是一组彼此关联的 skill。

一个 Agent 好不好用，是这一串 skill 能不能稳定衔接，能不能持续跑通，能不能在关键节点上把事情做好。

我越来越觉得，skill 的价值就在于把那些基础、繁琐、重复、低杠杆的工作标准化。

记录怎么进来，资料怎么抓取，内容怎么整理，结果怎么回写，信息怎么归档，很多脏活累活其实都适合先被 skill 化。

这样一来，dirty work 才能被稳定外包出去。

只有这些执行层真的被接住了，人才能把注意力留在更关键的节点上。


先迭代脚本和 skill，再造 Agent

做到这里，我对迭代顺序也越来越明确了。

第一层一定是脚本。

因为脚本最具体，解决的也是确定性最强、重复率最高的问题。

很多 dirty work 能不能真正自动化，最后都要落到脚本能不能稳定跑，能不能重复跑，能不能测出来。

第二层才是 skill。

当脚本开始稳定之后，才有必要往上抽象，把一类任务封装成一个稳定入口。

这样调用成本会越来越低，流程边界也会越来越清楚，原来零散的执行动作才会慢慢变成可复用的能力资产。

第三层才是 Agent。

Agent 也不是凭空长出来的。

它应该建立在脚本已经能跑、skill 已经有边界、流程已经有基本形状的前提上。

否则做出来的 Agent，往往只是看起来聪明，实际上并不稳定。

所以这个顺序不能反。

先把脚本打磨好，再把 skill 抽象清楚，最后再谈 Agent，才是更靠谱的路径。


Context, not control

再往前走一步，我还有一个越来越强的感受。

很多时候做 Agent，第一反应都是怎么把 control 做强。

多写一点 prompt，多加一点规则，多配几个 skill，最好把每一步都规定清楚。

但真正做下来之后我会发现，真正拉开效果上限的，往往是 context。

如果模型拿不到足够的目标信息、背景信息、历史记录、工作流状态和可用工具，那 skill 再多，也只是局部补丁。

相反，如果 context 足够完整，很多任务未必一定要提前做成一个专门的 skill。

模型只要拿到足够完整的目标和环境，反而更容易顺着任务自己往下做，最近这也是为什么Harness Engenieering开始出现。

所以我现在越来越重视的，是怎么把上下文准备得更完整。

复盘、资料库、知识库、项目文件夹、待办、日报、周报，这些东西表面上看是内容沉淀，往深一层看，其实都是在给模型准备 context。

所以在我的实践里，我会尽量把所有信息都收回到 Obsidian 这样的本地知识库里，少散在各个平台的云端。

把对的信息，在对的时刻，放进对的工作流里，这件事比多创建 skill 更重要。

把这段经验压成一句话，我现在会更相信：control 决定下限，context 决定上限。


OpenClaw 很火，但别急

最近一个月，OpenClaw 很火。

它火是有原因的，它确实做了交互创新，把 Agent 拉回到一个大家更熟悉的入口里。

不用再开一堆窗口，不用在一堆工具之间来回切，直接在 IM 里和 Agent 交互，体验上会顺很多，也更有活人感。

但问题也恰恰在这里。

很多人装 OpenClaw，是为了“装“，为了社交，为了跟上圈子里的热闹。

装上一个 Agent，看起来很先进，但这不等于你真的拥有了 Agent 能力。

真正能把这类 Agent 用好的前提，是底层有没有稳定的自动化能力。

得先有可测试的流程，先有能稳定跑的脚本，先有清晰的边界，先有足够完整的 context。

不然的话，Agent 接进来以后，效率未必放大，混乱一定会被放大。

在我看来，OpenClaw 更像一个放大器。

底层打得越稳，它越有价值。

底层没打稳，它就越容易变成表演。


我开始摸到下一阶段的产品形态了

写到这里，这轮升级带来的变化已经很具体了。

日常里越来越多的执行环节，已经开始稳定交给 AI。

认知资产也开始持续沉淀。

我不再把那么多精力浪费在搬运、整理、切换这些事情上。

这样省出来的注意力，最后还是会回到更重要的地方。

回到判断，回到决策，回到长期方向。

也正因为如此，我现在并不急着追求一个更炫的 Agent 形态。

下一阶段更重要的，还是先把底层执行层继续打稳。

等到有一天，我手里真的有了足够多能稳定协作的 Agent，我就可以借鉴 OpenClaw 这种形态，在一个统一的 IM 入口里管理我的 Agent Team。

如果那一天真的到了，我面对的也就不只是一个更好用的工具了。

那会更像我自己的 OPC，One Person Company。