v2yllhwa

25 码给我逗笑了，兄弟你太有文采了

终端获取到的公网 IPv6 是啥意思？
终端一般是一个全局地址，一个隐私地址，都是在一个前缀下面的，你之所以看到移动有三个可能只是隐私地址轮转的时候上一个还没失效

@little_cup 入了终身版一直在用，以前 mi push 能针对渠道关闭通知，对于没有这种能力或者划分不明确的系统，root 了固化为系统应用，确实非常好用

“量子”隧道，私有化部署，数据主权和安全，没有源码
这是否

@v2yllhwa 另外 google play 绑定国内卡订阅 claude 确实可行，我还没被封号过（去年到现在）

google 礼品卡校验地区非常严格，绑卡消费比较方便

question 1:
＞ [session context] 通告说"skill 列表已更新，新 skill 从下一个 session 可用"。这意味着用户装完 skill 想立刻用会发现用不了，要开新 session 。

＞ 但 invoke_skill 这个工具本身是始终存在的——它不需要 system prompt 里列出所有 skill 才能调用。模型可以通过 [session context] 通告知道新 skill 的名称，然后直接 invoke_skill(skill_name: "xxx")。


question 2:
＞ 不要做工作流编排。 多 Agent 在结构上就是 cache 灾难。人类的分工不对 AI 有任何价值。AI 是万能的。

＞ 这个设计一口气解决了好几个问题：
子 agent = 状态隔离
做代码审查的 skill 可能需要读几十个文件、跑 grep 、输出长篇分析。如果这些中间步骤都在主 agent 的 history 里，history 会膨胀得很快——cache 命中率没变，但上下文总量上去了，压缩触发得更早，成本更高。
子 agent 把这些中间过程隔离在自己的 session 里。主 agent 只看到最终结论。主 agent 的 history 没有被污染。


这两个地方是不是有一些前文和后文逻辑上的一些摩擦，是不是存在一些 trade off 和独特的设计？期待 op 分享一下。

比如第一个点我理解既然有 invoke_skill 工具是不是没必要在 session context 里说下一回合可用？直接说列表更新就 OK ？

第二个点咱们这个 agent 和传统的 sub agent 按角色的拆分是不是有一些设计上的不同？

看起来很不错，最近试用了 langgraph 和 smolagents ，一个太抽象，一个还不稳定。
楼主的 example 看起来挺优雅的。