推文 · 热度

希望大家不会用上的技巧之：
💡如何代理某个 docker 容器内所有的网络流量。

背景：
我想让某个跑在国内服务器上的 nestjs 应用支持下 google 登录。应用是跑在容器内的，所以你懂的，得代理下容器内所有与 https://t.co/Ua4slLfG9e 之间的请求。

方法👇：

发现了一些 Claude Code 隐藏的设计哲学！

最近 Claude Code 的更新，给 Skill 新增了 context:fork 的配置。相信各位对计算机科学有了解的话，应该对「Fork」这个词不陌生。如果你顺着这个词去发散的话，是不是会发现：

1️⃣ Skill 的 Context Fork 是不是有点类似「创建新进程」。而 SubAgent 运行时上下文隔离，是不是也和 OS 的进程隔离类似呢。
2️⃣ 那 Skill 岂不就是「应用」！文件夹就是资源包 (Assets)，Prompt 是业务逻辑 (Logic)，里面还封装了应用配置和数据。既可由用户手动运行，亦可被 Agent 自动调度。

这不妥妥的就是一个 Agent OS 么！

📌 置顶一条消息，长期有效。

目前我这有某 crypto 所的代理（高达 50%～90% 的手续费返佣），有兴趣的欢迎 dm 我。目前我自己的资金 & 策略已经在上面在跑了（中高频交易最大的敌人可能是手续费）😆过段时间我分享下情况

前前同事，从码农转行去做直播带货（幕后）后，一个月能分 10~15 个😳

谁说 Agent Client Protocol 只能给 GUI 用 🤣

Team/Swarm 模式很可能是 Coding Agent 在 2026 年真正爆发的关键方向。可以预见，每个主流 Coding Agent 都会推出自己的 Team Mode —— 但一个更有意思的问题是：怎么让不同厂商、不同架构的 Coding Agent 组成一个异构 Team？

目前市面上已经有一些尝试，但各有局限：

1. Headless 模式：通过 Coding Agent CLI 的 Headless 模式来编排多个 Agent。问题在于，各家的 Headless 模式普遍是阉割版——功能覆盖不全，交互能力也大打折扣，远不如完整的 CLI 交互体验。

2. PTY 劫持：直接通过伪终端（PTY）接管 Coding Agent CLI 的输入输出。这种方式虽然理论上能获取完整能力，但信噪比极低——你需要从大量终端控制字符、ANSI 转义序列和格式化输出中解析出真正有用的信息，既脆弱又难以维护。

而 ACP（Agent Client Protocol）提供了一个更优雅的解法。 它在 CLI 交互之上抽象出一层统一的、结构化的协议层，让上层编排系统无需关心底层 Agent 的具体实现细节，就能以一致的方式与不同的 Coding Agent 进行通信和协作。

基于这个思路，我做了一个开源项目来验证这个想法 👇

https://t.co/Sl1nMKd7Yq