iintothewind

感谢 op ，你这才是真正有价值的项目👍

@deplives thumb.db 和 desktop.ini 跟.DS_store 一样每个文件夹里面都有吗？
windows defender 能删除，kernel_task 你给我删一个？
windows 升级后对 app 兼容性比 mac 可好太多，mac 还想碰瓷这个？
没错，windows 不仅有安装反安装专用界面，连 winget 都是官方的，homebrew ？
我没说 powershell 好啊，咋的 powershell 做的差能证明苹果那套 genu 就好用？
windows 还真有安装反安装功能，苹果就是没有，你说破天就是没有啊，
PC 还真有很多软件是 x64 的而且无论从数量还是种类都不 arm 平台多，你这样反问倒是挺能颠倒黑白的。
你这是专业抬杠啊？

其实难用的是下面这些:

.DS_Store 满天飞：到处都是，永远清理不完，git 提交时总得手动删一遍

Finder 就是个摆设：终端根本不适合开发，还得配一堆第三方工具才能勉强用

kernel_task 发疯：CPU 占用突然飙到 100%，根本不知道它在干啥

强制升级地狱：过 1-2 年就逼你升级，兼容性问题一堆：不升则新应用打不开，升了旧应用又崩溃

没有 Homebrew 就是裸奔：macOS 的软件安装体验是个毛坯房，各种 pyenv 、nvm 、rbenv 搞得乱七八糟

bash 不是 GNU-Bash：跟 Linux 完全不通用，alias 、history 的行为都不一样，命令行工具经常要改参数

App Store 的封闭生态：不在 App Store 里的软件就不算"应用"了吧？而且 App Store 里好用的必须付费，免费的肯定有广告，又好用又免费的几乎没有

没有真正的卸载：装个软件，卸载后一堆垃圾残留，还得手动去/Library/Application Support 里清理

ARM 架构的坑：很多 x86 软件跑不起来，或者只能用 Rosetta 转译，性能损失严重

闭源驱动不支持：打印机、扫描仪、USB 设备经常识别不了，还得专门去找驱动

标题和正文对不上。

少调用和并行是两条不同的优化思路：一个靠减少交互次数，一个靠单回合批量塞活。前者省往返，后者省的是串行等待、代价是单回合决策变重。你标题要前者，正文吹后者，俩叠一块，既不省决策也不省理解——到底想优化哪头？

感觉逻你的引流简述的逻辑有点混乱,就不想点开看了.

是谁这么想在赛博炼狱享受永恒折磨呢?

我觉得按一辈子的长度的话, 100w 其实不多, 但是你真的有 100w, 对普通人, 那可是不少的钱了. 而且是单身一个人, 想躺平一会怎么就不行, 躺平又不是进棺材, 中国人也不是只能有一种活法.

个人理解的,agent 设计上 工具能力的优先级排序，

**我的排序：build-in tools > Skills > CLI > MCP**

几个理由：

**1. build-in tools 理应最高优先级**

Agent 的 built-in tools 是它的「母语」—— 调用约定、返回值结构、错误处理全是原生默契。如果 built-in tools 在性能、token 效率或可操作性上不如外部方案，那该反省的是 Agent 本身的实现质量。作为使用者，如果发现一个 Agent 的 native tool 能力弱到需要频繁绕道外部工具，可能该考虑换个 Agent 了。当然长尾领域不可能全部覆盖，这是现实限制，但当 native tool 能覆盖时，优先用它。

**2. Skills > CLI**

Skill 本质上是经过提纯和定制的 CLI 能力 —— 把 CLI 用法、参数说明、输出格式、注意事项打包成一个按需加载的 markdown 文件。它比裸 CLI 多了「怎么用」的说明，Agent 读一次就知道怎么调，不需要试错。所以它优先于 CLI 。

**3. CLI > MCP**

CLI 虽然不完美 —— 非结构化输出需要 Agent 自己 parse 、管道链组合对模型推理能力要求高、交互式 CLI 基本不可用 —— 但至少轻量，不需要常驻进程。MCP 的问题在于：
- 全量 schema 灌进 prompt ，上下文膨胀
- 需要后台维持 server 进程/连接
- 很多时候你只想要一个 tool ，但一装就是一整组

MCP 的理论优势是标准化和动态发现，实际代价偏高。

**CLI 内部也有分化**：带 `--json` 输出的 CLI 接近 MCP 的结构化程度；管道链组合对模型是认知负担，因为没有类型检查的「胶水代码」；交互式 CLI 基本跟 Agent 无缘。

**MCP 不算完全鸡肋**，有一个 Skills 和裸 CLI 都做不到的事：返回结构化类型数据，Agent 不需要从文本里 regex 提取结果。但它的适用场景更偏向「动态变化的数据源」（实时 API 、数据库查询），而 Skills 更适合「静态固定的操作」（特定 CLI 工具的用法）。两者场景不完全重叠。

---

跟主楼的关系：这不算反驳，更像是补充一个执行层面的视角。主楼分析的是某些 Agent 产品实际上怎么处理冲突（工具名覆盖、注册表优先级），上面说的是我个人理解的在 Agent 设计上应该怎么定优先级。两者可以对照着看。