@Leechael
群里面看到有个开发者去世了。心源性猝死View quoted post on X
群友整理了他在群内的一些发言：
6 月 10 日 17:14：谈维护复杂项目，说“有AI帮忙都搞到心力憔悴”。
7 月 15 日 20:30：“还没用完了，晚上又要熬夜了。”
8 月 11 日 21:11：“连续两个要到期的重置，今天和明天都要熬夜加班了。”
8 月 27 日 20:19：“今晚不睡觉。”
10 月 23 日 03:07：“还一个三点到期的重置，赶紧又跑了50%重置成功。累死。”随后说“两小时内连着重置两次”。
其实死亡离我们很近，多给自己放个假。
希望大家都身体健康！
昨天让 Grok Bot 帮我盯一下 DMIT 的补货，结果一天用了我 100 刀套餐一周的 30% 额度，气晕了 😭View quoted post on X
我本来周初想写 webhook is all your need，说一下为什么我觉得 agent 协助到最后就是一堆 webhook ，可惜忙起来就忘得七七八八了；现在随收写一下 llm 对于 tool 的偏好和自己对 personal agent 的想法；主要就是这周重度使用的一个 tool：monitor。View quoted post on X
这是我自制 Pi 插件中的一个 tool，用途就是让 agent loop 运行的时候有一个长期运行的进程在跑一个命令，最简单的例子就是 tail -f 监控日志输出，搭配 awk / grep （好吧现在脚本都是 agent 写的，我根本不知道它写什么了），可以做到 streaming 日志在出现特定特征时 emit 一行输出到 stdout。这本质有点像是事件驱动，因为老 SRE 都知道，配合 awk scripting （重复，AI 现在都是写 Python 了……），你完全可以让 agent 观察特征，然后自行进行操作，譬如，看到 nginx access log 中的 500 就自己去开 issue，看到 Request Time P50 指标异常了就 alert，或者盯着有没有大规模 sniffing 行为和入侵行为（是的，这周我又因为这个事情忙了好几天）。
在这个背景下，llm 缓存会过期得非常快；而且由于一直在跑（可能每天我就跑去问一句最近 8 / 12 / 24 小时的情况），这个消费金额可能就会非常高。因此，deepseek v4.1 flash 意外地好使，1M 的长上下文，低廉的价格。我原本尝试用 GPT 6 Luna，结果短上下文和经常跑偏，反而不好用了。
罗嗦了一堆背景，接下来就可以继续说 monitor 这个 tool 了。你会发现 llm 的后训练还是有提升空间（按照前面某次和某模型厂小伙伴的聊天），因为在 eval 评估中，几乎没有哪个模型会主动选择 persistent monitor，都是选择 5 minutes 左右的过期时间。这也意味着，除非你指令上明确说明用 peristent monitor，哪怕你 tool 的说明写得再明白。tool description 的权重我们应该可以理解和 system prompt 不是一个维度的；但是有什么 tool ，又可能是 llm 缓存中构成位置更前因素。
除了我上述说的这个 tool，在早几个月前的一次 eval 结果也能说清楚模型在训练时的偏好。当时候我希望 agent 直接输出的文字不要作为聊天对话直接发送给我，而是通过一个 send_message 的 tool 发送（让它自己判断是否需要给我发信息），以及安排了一个名为 handover 的 tool：这个 tool 的主要作用就是主动清理上下文，譬如感觉聊的某个主题要结束了，那么就应该判断当前聊天中的上下文有多少是需要保留到下一次对话的；这个 idea 来自于 Tape （ tape.systems )，只是我把浮标操作权给到了模型。
当时在 agent 中使用的 llm 还是 k2.7 和 deepseek v4 flash，偶尔还会切换到 gpt 5.5，结果表现的结果就非常不一样，如果我没有记错的话，当时体感非常明显的是经常聊着聊着出现“失忆”的表现——那就明显是 agent 自己判断应该 handover 了，主动清理了上下文，结果就是“这天没法聊了”。
这两个小事配合 codex 的 codemode （以及 Pi 增加 codemode ）来看，我们明显发现在做 Agent 或者 Harness 的时候，无可避免地要考虑模型的偏好。你增加的 tool ，你的 harness engieering 设计，或者只能是搭配某个模型和某个使用范式下，才可能出现 aha moment，而其他人是没法和你共鸣的 —— 谁又天天用得起 Opus 和 Astra，难道普通人在使用 Personal Agent 时不好的体感，你能归咎去 skill issue？
这个事情其实可以和 Grok Bot 最近的降智事件一起说。从成本角度出发，Grok Bot 更换模型是无可避免的事情，单问题在于 Grok Bot 的构建——整个 harness 是基于某个模型作为基础进行构建的，如果更换了模型，其实整个体验就会出现变化，这个变化在规模化使用中是很难衡量的——天天在用的工程师，可能调整一下自己的使用习惯和说话方式（所谓 SKILL ISSUE）就磨平了，但是普通人并非这样。这个情况也在年初的 Manus 上出现过；当时我非常喜欢通过 manus 来做 random idea 的 research，因为主动性非常好，但是后来味道感觉有变：我随便问个问题，它居然是先反问我一个问题。原来的主动性没了。从企业角度，这个 token 成本可能降下来去，因为强迫把问题扔给用户，用户先行进行思考、回复，具象化问题然后模型/agent 再去干活，能得到更好的答案，但是谁又会想这样去处理这个事呢？我们使用 AI，也是因为有未知的问题，需要你去解决啊？
或者 Grok Bot - 它不应该更换模型，而是借着这一波的数据，用来给 grok 做蒸馏和后训练；然后使用一个推理成本更低的模型来作为 grok bot 的基座模型——或者这个才是 personal agent 能有效降低成本的路子。
我本来周初想写 webhook is all your need，说一下为什么我觉得 agent 协助到最后就是一堆 webhook ，可惜忙起来就忘得七七八八了；现在随收写一下 llm 对于 tool 的偏好和自己对 personal agent 的想法；主要就是这周重度使用的一个 tool：monitor。View quoted post on X
这是我自制 Pi 插件中的一个 tool，用途就是让 agent loop 运行的时候有一个长期运行的进程在跑一个命令，最简单的例子就是 tail -f 监控日志输出，搭配 awk / grep （好吧现在脚本都是 agent 写的，我根本不知道它写什么了），可以做到 streaming 日志在出现特定特征时 emit 一行输出到 stdout。这本质有点像是事件驱动，因为老 SRE 都知道，配合 awk scripting （重复，AI 现在都是写 Python 了……），你完全可以让 agent 观察特征，然后自行进行操作，譬如，看到 nginx access log 中的 500 就自己去开 issue，看到 Request Time P50 指标异常了就 alert，或者盯着有没有大规模 sniffing 行为和入侵行为（是的，这周我又因为这个事情忙了好几天）。
在这个背景下，llm 缓存会过期得非常快；而且由于一直在跑（可能每天我就跑去问一句最近 8 / 12 / 24 小时的情况），这个消费金额可能就会非常高。因此，deepseek v4.1 flash 意外地好使，1M 的长上下文，低廉的价格。我原本尝试用 GPT 6 Luna，结果短上下文和经常跑偏，反而不好用了。
罗嗦了一堆背景，接下来就可以继续说 monitor 这个 tool 了。你会发现 llm 的后训练还是有提升空间（按照前面某次和某模型厂小伙伴的聊天），因为在 eval 评估中，几乎没有哪个模型会主动选择 persistent monitor，都是选择 5 minutes 左右的过期时间。这也意味着，除非你指令上明确说明用 peristent monitor，哪怕你 tool 的说明写得再明白。tool description 的权重我们应该可以理解和 system prompt 不是一个维度的；但是有什么 tool ，又可能是 llm 缓存中构成位置更前因素。
除了我上述说的这个 tool，在早几个月前的一次 eval 结果也能说清楚模型在训练时的偏好。当时候我希望 agent 直接输出的文字不要作为聊天对话直接发送给我，而是通过一个 send_message 的 tool 发送（让它自己判断是否需要给我发信息），以及安排了一个名为 handover 的 tool：这个 tool 的主要作用就是主动清理上下文，譬如感觉聊的某个主题要结束了，那么就应该判断当前聊天中的上下文有多少是需要保留到下一次对话的；这个 idea 来自于 Tape （ tape.systems )，只是我把浮标操作权给到了模型。
当时在 agent 中使用的 llm 还是 k2.7 和 deepseek v4 flash，偶尔还会切换到 gpt 5.5，结果表现的结果就非常不一样，如果我没有记错的话，当时体感非常明显的是经常聊着聊着出现“失忆”的表现——那就明显是 agent 自己判断应该 handover 了，主动清理了上下文，结果就是“这天没法聊了”。
这两个小事配合 codex 的 codemode （以及 Pi 增加 codemode ）来看，我们明显发现在做 Agent 或者 Harness 的时候，无可避免地要考虑模型的偏好。你增加的 tool ，你的 harness engieering 设计，或者只能是搭配某个模型和某个使用范式下，才可能出现 aha moment，而其他人是没法和你共鸣的 —— 谁又天天用得起 Opus 和 Astra，难道普通人在使用 Personal Agent 时不好的体感，你能归咎去 skill issue？
这个事情其实可以和 Grok Bot 最近的降智事件一起说。从成本角度出发，Grok Bot 更换模型是无可避免的事情，单问题在于 Grok Bot 的构建——整个 harness 是基于某个模型作为基础进行构建的，如果更换了模型，其实整个体验就会出现变化，这个变化在规模化使用中是很难衡量的——天天在用的工程师，可能调整一下自己的使用习惯和说话方式（所谓 SKILL ISSUE）就磨平了，但是普通人并非这样。这个情况也在年初的 Manus 上出现过；当时我非常喜欢通过 manus 来做 random idea 的 research，因为主动性非常好，但是后来味道感觉有变：我随便问个问题，它居然是先反问我一个问题。原来的主动性没了。从企业角度，这个 token 成本可能降下来去，因为强迫把问题扔给用户，用户先行进行思考、回复，具象化问题然后模型/agent 再去干活，能得到更好的答案，但是谁又会想这样去处理这个事呢？我们使用 AI，也是因为有未知的问题，需要你去解决啊？
或者 Grok Bot - 它不应该更换模型，而是借着这一波的数据，用来给 grok 做蒸馏和后训练；然后使用一个推理成本更低的模型来作为 grok bot 的基座模型——或者这个才是 personal agent 能有效降低成本的路子。
