前段时间刚好在折腾类似的东西，拿 agent 做了一轮线下门店的经营数据分析，最深的感觉就是 skill 写得细不细差别巨大——同样一句"帮我看看这个月的营业额变化"，没有工作流约束的时候它就给你算个总数完事，把分析步骤拆清楚之后才会老老实实先对口径、再分渠道拆、最后给异常点。 所以官方这份泄漏出来的 skill 结构挺有参考价值的，特别是职责边界和关联技能那部分，等于告诉你一个成熟的分析 age

更新：没想到这么多朋友感兴趣，坦白说下——这就是我们在做的产品，叫快咔截图，官网 kuaika.app ，上面说的这套引擎就是它的核心。目前可以下载用了，Windows / macOS 都有。帖子里踩的坑基本都还在持续优化（尤其是查询理解和多语言混排这两块），大家用了有任何问题直接在这里回或者私信我，都欢迎。开源的事我们在认真考虑，有进展会第一时间在这个帖子里更新。

云端做 OCR 的那些（网盘、相册类）思路确实类似，都是「图片 → 文字 → 建索引」。不过我最后选本地自建，主要是两个现实原因： 一是隐私和范围。云端方案只能扫「传上去的」，我这堆截图里不少是工作相关的（配置、代码片段、聊天记录截屏），不太想整包交给云。本地跑 OCR 虽然慢点，但几百 G 的历史截图一次索引完，之后查询都在自己机器上。 二是查询这一环。识别出文字只是一半，真正的难点是我记不清原

这里是我表述不严谨，抱歉。实际情况是那个项目我自己写过一部分，对结构有先验，知道配置大概在哪一层，模型实际是返了一次确认路径才命中的，不是纯靠模型一次到位。拿这个当「长上下文能力提升」的证据确实夸大了，样本就一天，大家参考时打个折扣看。