kabikabi (@jakevin7)

做 Agent 有个不成文的默认假设：tool result 很重要，模型要看完原文才能继续推理。 最近发现这个假设可能是错的。 ---------------------------------- 欢迎 star ---------------------------------- 在 maka 里，我们对 tool result 做了激进的 prune——把工具返回的原始数据大幅裁剪，只保留关键摘要，然后跑了完整的任务对比。结论让人意外：推理质量几乎没有变化，近乎无损压缩。 这是为什么？我有几个可能的解释： 第一，信息已经被蒸馏进 Assistant Message Agent loop 的上下文结构是： System Prompt → User → Assistant → Tool Use → Tool Result → Assistant → ... 每次 tool result 之后，模型都会输出一段 Assistant Message 来表达它的理解和下一步决策。这是一次语义蒸馏——原始数据被压缩成了推理摘要。 后续轮次的模型，更多是在跟"它自己的理解"对话，而不是在跟 tool result 原文对话。prune 掉原文，相当于删掉了一份已经被读取并转化的档案——信息早就走了，外壳还在而已。 第二，Attention 在长上下文里本来就稀疏 "Lost in the Middle" 那篇研究证明：Transformer 对长上下文中间段的注意力权重会大幅衰减，模型更关注开头（system prompt）和最近几轮。 Tool result 通常在上下文中间位置，而且信息密度极低（500 行代码、终端输出、冗余 JSON）。模型本来就没在认真"读"它。prune 只是把这部分被隐式忽略的内容显式删掉。 第三，决策点已经过去 模型调用工具是因为当时需要那个信息。但 5 轮之后，那个 tool result 早已不是边际信息了——核心内容已被消化进后续推理链，保留原文是"存档"，不是"决策输入"。 实测数据：对同一个任务（MIPS interpreter），Maka 的总 token 消耗只有 OpenCode 的 38%，但 output token 是它的 2.7 倍。 这个差距背后，有 DeepSeek cache 命中率 95% 的贡献，也有 tool result prune 的贡献。两者合力，长程任务的 token 经济性出现了量级跃升。 对 Agent 工程的启示：context 里最占体积的部分，不一定是最重要的部分。 与其把精力放在"怎么让 tool result 完整进上下文"，不如放在"模型读完之后的 reasoning 质量"上。信息的真正载体不是原文，是理解。

OpenCLI App 发布了！🥳🥳 现在不需要 npm 就可以使用 OpenCLI，方便普通用户使用。并且集成了一些其他的方便使用的功能，包括自动刷新登录态等。 欢迎使用，有问题直接dm我或者评论区发我，或者软件内的反馈部分反馈给我。

2w followers 了，感谢每一个人。 在推上学到许多，整个过程也希望是自己成长的过程。 以前做的好不好不重要，未来希望自己能够一直变好。

把之前做的 agent: maka 开源出来了，目前还在高密度开发中： 现在已经有这么多开源的Agent了，那为什么还要自己做一个呢？ - maka首先是一个桌面版 Agent，未来机会会出现无头模式。maka 不是 TUI，而是 local-first agent。 - 我们引入了 workflow 的机制给 maka，通过 DAG 的形式来让 AI 长程执行而不是仅仅 Loop。 - 希望做一个良好的插件能力，希望每个人都能定制化的加上每个人能自己用的功能。 - 内嵌入浏览器，集成强大的浏览器自动化能力 - .... 目前maka还在紧锣密鼓开发中，我们现在有一个小的 core 团队，会通过 slock & 自己的 agent 进行协作开发。

大时代下的我们和不可抗拒的洪流。 过去的时代已经不在了，缅怀也没有意义，只能向前看。 现在听 杀死那个石家庄人 太唏嘘了了。 “生活在经验里，直到大厦崩塌”

OpenCLI 一键打通 Agent 的 Twitter 世界！🚀 发推、回复、引用转推、监控通知、关键词触发自动回 DM、把整条 thread 抓下来总结、批量整理 list、定期备份某个人的所有图和视频——你想到的客户端操作，Agent 都能替你跑。 不需要 X API key。不需要等审批。不用 OAuth 折腾半天。 全部复用浏览器登录态——你能在网页上做的事，Agent 都能做。 OpenCLI 的 Twitter 适配器膨胀到 36 个命令，几乎打穿整个客户端： 读：timeline / search / thread / tweets / likes / followers / following / bookmarks / notifications / trending / article / download 写：post / reply / quote / retweet / like / bookmark / follow / block / hide-reply / delete DM：reply-dm / accept 关键词自动放行 List：lists / list-tweets / list-add / list-remove 以前 Agent 看 Twitter 只能爬时间线 现在 search → thread 抓完整讨论 → 总结 → quote / reply 发出去，一条流水线串到底 Twitter 是 Agent 的第一个完整生活场景。

这几天把 xiaohongshu-cli 连续打磨了一轮，做了几件我自己很满意的事： 1. 放弃了没必要的 server 方案，回到纯 CLI，但把真正有价值的状态能力保住了： - xsec_token + xsec_source 成对缓存 - search 更像浏览器真实请求链 - search_id / note context 复用 - read / comments / reread 的连续链路更稳 2. 补了一整套真实只读 smoke tests，不只是单测 直接验证： search -> read -> comments -> feed -> reread 这类连续场景在真实登录态下能不能跑通 3. 做了短索引交互 现在不光能： - xhs read 1 - xhs comments 1 还支持： - xhs like 1 - xhs favorite 1 - xhs unfavorite 1 - xhs comment 1 -c "..." - xhs reply 1 --comment-id ... -c "..." 而且 search / feed / hot / user-posts / favorites / my-notes 都会刷新索引。 顺手还吸收并重做了社区 PR 的产品思路，把实现按当前主线重构了一遍，避免把新的 anti-blocking 逻辑回退掉。 最新版本：v0.6.3