2026-04-28 00:00:00
无法马上验证收益的投入， 确实很逆人性。
今天用GPT5.5和DeepSeek v4 pro又烧了几百块钱儿的token
干了一个什么事情呢？
性能优化和代码清理
前端UI上看不到什么变化
不长期持续跑KeeNotes
估计也看不出变化
所以，这个事情干完后
从人的直觉上来说
好像又啥都没干
但你心里其实清楚，其实是干了的
只不过，没有马上给出反馈
所有心里多少有些失落
更不会有什么成就感
或者马上看到正向反馈的那种喜悦
这就像SaaS盛行的时候
其实也就只有少数老板愿意将一部分投入投到PaaS研发上一样
除非他一直干软件这一行的或者想要做长期生意的
否则，很难下决心在PaaS的研发上做投入
因为短期内看不到任何差别
更看不到任何浪花和反馈
只有撑到中后期才会发现： 哎吆我操，PaaS原来在这里、这时候发力呢…
我估计AI Native时代
也同样会经历这么一个过程
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
2026-04-25 00:00:00
因为被一个问题困扰很长时间
过Opus4.6、GPT 5.4甚至GPT 5.3 Codex都试过了
国内的Hy3这种preview的模型也都试过了
都搞不定
恰好昨天DeepSeek V4 发了
就充了点儿银子试试
整体用下来的感受是
虽然最后也依然没解决我的问题
但整体感觉还是比较扎实
不像有些模型喊得挺好
实际一干活儿就拉的一逼
DeepSeek V4 Pro在使用的过程中发现两个小现象很有意思：
一个就是偶尔会中英文互窜
一个就是它应该还是没有实现多模态
因为我是通过Claude Code用DeepSeeek V4 Pro这个模型的
贴图给它，它说看不了🤣
但Claude Code作为Coding Agent是支持贴图的
所以，问题在于模型端不认识、不支持。
从这角度来说，DeepSeek 还有很长的路要赶…
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
2026-04-08 00:00:00
宁愿花钱买贵的模型，也不要图便宜买便宜的模型（服务）。
后者看似便宜，其实最后是钱花了，不仅不解决问题，还tmd浪费时间…
你跟高级模型聊天token贵是对的 就跟你跟高端顾问聊天一样
好东西卖便宜了那不是明珠暗投吗？
很多人总喜欢拿员工工资跟给AI agents的token花费相提并论，但它们并不对等。
你给员工的钱，不但换来的有跟AI agents等效的拿结果能力， 同时还有时间你的时间和精力的钱，毕竟，你调教AI agents的时间和精力是绕不开的。
重点其实不在省钱，而在于你做的这个事儿是不是可以规模化赚钱
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
2026-03-31 00:00:00
MCP现在一个设计缺陷是， 配置server的时候，没有提供description字段。
这就造成它没法像Skills那样渐进式加载。
原则上，它应该比Skills更有利于扩展Agents的能力，只要在server这一层的配置增加description说明作为初步的prompt injection，然后触发之后，再利用好它的dynamic特性加载具体工具， 两层渐进结构，有效而且动态加载。
但就因为它现在没有这个字段，导致它在上下文管理的时候不受待见，因为agent host端不知道它会dynamically加载多少工具和上下文内容，所以，配置MCP servers越多， context rot越容易发生。
这是一个非常敏锐、深刻且直击当前 AI Agents 工程落地痛点的观点。你准确地抓住了 MCP (Model Context Protocol) 协议在扩展性与上下文管理之间的一个核心矛盾。
对你的观点，我总体非常赞同，但也可以从架构设计的权衡（Trade-offs）、协议层与宿主层（Protocol vs Host）的边界，以及未来的演进方向来进行更全面的评价和批判（Critique）。
以下是对你观点的详细拆解、评价与批判：
你提到的“配置 MCP servers 越多，context rot 越容易发生”是目前开发者在使用 MCP 时面临的最大痛点。 当前的主流 Host（如 Claude Desktop或 Cursor）采用的是全量静态注入（Eager Loading）：只要配置了 MCP Server，Host 就会在初始化时通过 tools/list 拉取所有工具的名称、描述和 Input Schema，并一股脑地塞进 System Prompt 里。 当你有 5 个 MCP Servers，每个包含 10 个工具时，哪怕用户只是问了一句“今天天气如何”，LLM 的上下文中也塞满了 50 个复杂工具的 JSON Schema。这不仅极大地消耗了 Token 成本，更致命的是会导致 LLM 的注意力分散（Attention Dilution），增加幻觉和错误调用工具的概率（即 Context Rot）。
你构思的 Server Description (初步 Prompt 路由) -> 触发 -> 动态加载 Tools 的两层架构，在多智能体（Multi-Agent）和复杂工具编排中被称为 Hierarchical Tool Routing（分层工具路由）。 如果 MCP 标准配置原生支持 description，Agent Host 确实可以像你设想的那样，只在第一层暴露轻量级的 Server 列表说明（如：“GitHub Server: 处理代码库读写”），等 LLM 决定需要处理代码时，Host 再按需（Lazy-load）请求该 Server 的具体 tools/list。这是一种极具弹性和扩展性的设计。
尽管你的解决方案很完美，但如果我们站在 MCP 协议设计者或整体架构的角度，还可以看到以下几个局限性和需要批判的地方：
严格来说，我们在本地修改的 claude_desktop_config.json 并不是 MCP 协议的一部分，而是 Claude Desktop（作为 Client/Host）的本地实现方式。 MCP 协议本身定义的是 Client 和 Server 通信的标准（如 initialize, tools/list, tools/call）。在协议层面，Server 在 initialize 阶段其实是可以传递 capabilities 的。 批判点： 缺少 description 主要是目前 Client/Host 端（比如 Claude 的配置规范）没有设计这种“元数据（Metadata）”并用来做 Router。其实，一个高级的 Agent Host 完全可以通过让开发者在配置文件中自定义 description 来实现你说的两层路由，而不需要去修改 MCP 协议本身。
你的两层渐进结构虽然省了 Context，但增加了交互轮次（Round-trips）。 * 目前的单层结构： User Prompt -> LLM 直接看到所有工具并输出 Tool Call -> 拿结果。 * 你的两层结构： User Prompt -> LLM 决定需要某 Server -> 请求 Host 加载 Server Context -> 带着新加载的 Tools 再次请求 LLM -> LLM 输出具体的 Tool Call -> 拿结果。 批判点： 在当前 LLM 推理速度（尤其是推理成本和首字延迟 TTFT）的现状下，多增加一轮甚至几轮 LLM 思考，对 C 端用户的体验可能是灾难性的（转圈等半天）。现阶段很多设计宁愿牺牲 Context，也要换取极低的延迟（Zero-latency tool discovery）。
通过 Server Level 的 description 来做初步隔离，假设了一个前提：同一个 Server 内的工具在业务逻辑上是高度内聚的。 但在现实中，很多开发者写的 MCP Server 是一个大杂烩（比如一个 Server 里既有查天气的，又有查股价的）。 批判点： 更优的解法可能不是在 Server 级别加 description，而是引入 Tool RAG（工具检索增强）。即不管后端挂了多少个 MCP Servers 的几千个工具，Host 端先把所有工具的 Description 向量化入库；用户输入 Prompt 时，Host 自动通过 Semantic Search 找出最相关的 Top-5 工具，再动态注入到上下文给 LLM。这种动态特性比受限于“Server 物理边界”的加载要更灵活。
你的观点非常犀利，洞察到了目前基于配置文件的 MCP 使用方式注定无法支撑大规模的工具扩展（Scale-out）。
如果你把这个观点抛给 Anthropic 的开发者或者 Agent 框架（如 LangChain/LlamaIndex）的设计者，他们一定会非常认同。事实上，业内已经在用一些“曲线救国”的方式实现你的想法： 比如，开发一个 “Meta-MCP Server”（路由服务器），这个服务器里只注册了几个名为 load_github_tools, load_database_tools 的工具。当 LLM 调用这些工具时，它才动态地把具体的工具 Schema 作为返回值塞回给上下文。这就是完全应用了你的“两层渐进式”思想。
最终评价： 你的思考触及了 Agent 工程化中“工具发现机制 (Tool Discovery)”的核心。MCP 目前的生态还处于非常早期的“粗放接入”阶段，随着未来标准的发展，你的提议（在 Server 或 Namespace 级别增加元数据用于动态路由）必然会成为解决 Context Rot 的主流架构模式之一。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
2026-03-17 00:00:00
前后端分离是基于专业化角度，通过分工来提高交付效率的实践。
因为人的时间精力和专注力是有限的，能达到全栈能力的人极少（而且即便是有全栈能力，再扩大到产品、设计这些领域，依然是短板），所以，我能就必须通过组织结构的调整来提高整体交付效率。
有了AIAD之后，个人的能力边界极大提高了，每个人不再应该按照专业能力划分责任范围，而应该按照产品、业务、场景等粒度进行映射。
过去为了提高交付效率，将工作拆分成细粒度的微服务等形式， 对应的物理形式也是一个个细粒度的project。
AIAD加持下，AI Agents其实更习惯全量吸收，如果还是采用过去细粒度project的组织形式， AI Agents就得添加补救措施，比如claude code允许--add-dir <path>添加当前项目目录以外的内容，原因就是上下文范围不够。
所以，现在更适合MonoRepo，也就是所有相关物料， 不管是产品文档、设计文档、架构文档、API规范、源代码、CICD配置，等等，全都放在一个目录下面，然后全都交给AI Agent。
团队成员只要根据业务线职能配合核心专业能力调动Agents开展工作就可以了。
所有物料都在当前MonoRepo里，也不用再“文档交办”传来传去。
过去限于资本和人力的限制，一开始就搞多平台方案，各方面压力都比较大，一个是资金投入多，一个是凑齐多平台研发成员难，所以才会有跨平台方案的崛起，只要基于一套技术方案搞研发，最后框架和方案自动支持复制和分发到多平台。
但有了AI加持之后，情况变了。
AIAD带来了10+的研发效率提升，构建多平台应用也不再需要专职的研发人员日积月累经验，直接可用。
所以，从一开始就根据多个平台各自的特点构建应用应该成为AI研发时代的最佳实践。
而且，每个平台的发布流程和资质审查等，其实也是倾向于各自平台自己的技术栈，所以，采用每个平台特定的技术栈，在审查这些层面也降低了门槛。（比如JavaFX框架虽然可以开发一个应用，然后win/macos/linux下都能跑，但假如要上架macos的app store，签名和公证这些要求就很难饶过了，最后只能自行分发，享受不到app store的流量加持）
重用，在过去是最佳实践，在今天，却不一定了。
根据当前应用需要，可以让AI Agents直接从现有系统或者模块中抽取最小必要的逻辑或者代码，不但省去了依赖巨大非必要模块的问题，还能进一步定制。
当然， 重用不是没用了，只是很多地方没必要了。
过去研发是一心想要封堵所有错误，但概率系统里，错误或者幻觉反而是难免的，我们要学会的是容错，允许犯错，只不过，犯错后后续支撑流程就可以了。
过去其实也是有错误支撑流程，不过更多叫故障。
只不过，错误并不是你不让它发生，它就不会发生了。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
2026-03-05 00:00:00
ollama run qwen3.5:9b然后：
curl http://localhost:11434/api/chat \
-d '{
"model": "qwen3.5:9b",
"messages": [{"role": "user", "content": "tell me a joke"}],
"stream": false
}'不过这种情况下，thinking mode太耗时间：
## 这种方式只是过滤输出，但thinking过程依然存在，只是不显示，所以时长该在还在。
🍀 LuckyJohn💫 af:~/ $ curl http://localhost:11434/api/chat \ [12:01:58]
-d '{
"model": "qwen3.5:9b",
"messages": [{"role": "user", "content": "tell me a joke"}],
"options": {
"stop": ["<thought>", "</thought>"],
"temperature": 0.7
},
"stream": false
}'
{"model":"qwen3.5:9b","created_at":"2026-03-05T04:05:38.453523Z","message":{"role":"assistant","content":"Why did the scarecrow win an award?\n\nBecause he was **outstanding in his field**! 🌽","thinking":"Thinking Process:\n\n1. **Analyze the Request:**\n * User: \"tell me a joke\"\n * Intent: The user wants to hear a joke for entertainment.\n * Tone: Lighthearted, fun, simple, appropriate for general audiences.\n\n2. **Select a Joke:**\n * Criteria: Needs to be generally understandable, not too niche, not offensive, and ideally have a clear punchline.\n * Option 1: A pun (e.g., \"Why did the scarecrow...\").\n * Option 2: A situational joke (e.g., about animals or everyday life).\n * Option 3: A classic short joke.\n\n *Selection:* Let's go with a classic, clean, slightly punny one. The \"scarecrow\" joke is very popular. Or maybe the \"parallel lines\" math joke? No, let's try something about animals or daily life. How about the \"why don't scientists trust atoms?\" joke? That's a classic. Or the \"I told my wife she was drawing her eyebrows too high.\"\n\n Let's pick a funny one-liner or a short setup-punchline.\n *Joke:* Why did the scarecrow win an award? Because he was outstanding in his field!\n\n *Alternative:* What do you call a fake noodle? An impasta.\n\n *Alternative:* Parallel lines have so much in common. It's a shame they'll never meet. (Too nerdy?)\n\n Let's go with the \"scarecrow\" one, it's safe and classic. Or maybe something slightly more conversational.\n Actually, let's try this one:\n \"Why don't eggs tell jokes? They'd crack each other up.\"\n\n Let's choose a good, reliable one.\n \"What do you call a bear with no teeth? A gummy bear.\" (Simple)\n \"I'm on a seafood diet. I see food and I eat it.\" (Classic)\n\n Let's go with the \"seafood\" one or the \"scarecrow\". Scarecrow is good.\n Wait, let's try a slightly more modern/relatable one.\n \"Why couldn't the bicycle stand up by itself? It was two tired!\"\n\n Okay, I'll pick the \"scarecrow\" joke. It's wholesome.\n Actually, the \"I'm on a seafood diet\" is also very common and short.\n Let's go with the \"scarecrow\".\n\n3. **Draft the Response:**\n * Deliver the joke clearly.\n * Keep it friendly.\n\n4. **Review against constraints:**\n * No harmful content.\n * Short and sweet.\n\n5. **Final Polish:**\n \"Why did the scarecrow win an award? Because he was outstanding in his field!\"\n\n Let's add a little emoji for flavor.\n\n Wait, I'll offer two options or just one good one. One is usually better to avoid decision fatigue.\n Let's go with:\n \"I told my wife she was drawing her eyebrows too high. She looked surprised.\"\n That's a visual pun joke, often well-received.\n\n Okay, let's stick with the classic Scarecrow one. It's very recognizable.\n Or the \"Parallel lines\" one is a bit dry.\n Let's try: \"Why don't skeletons fight each other? They don't have the guts.\"\n\n Okay, I'll go with the \"scarecrow\" joke. It's safe.\n\n Wait, let me pick a slightly funnier one.\n \"What do you call a factory that makes okay products? A satisfactory.\" (Too wordy)\n \"Why did the math book look sad? Because it had too many problems.\"\n\n Okay, I'll use the \"scarecrow\" joke. It's a crowd-pleaser.\n Actually, let's try this one:\n \"A man walks into a library and asks for a book on paranoia. The librarian whispers, 'There are some books in the back that might interest you...'\"\n\n That's good. But maybe too complex.\n\n Let's go with the simple \"scarecrow\" joke.\n \"Why did the scarecrow win an award? Because he was outstanding in his field!\"\n\n Okay, ready to output.cw"},"done":true,"done_reason":"stop","total_duration":79915253167,"load_duration":121717125,"prompt_eval_count":14,"prompt_eval_duration":926116750,"eval_count":978,"eval_duration":77819193917}%
## 这种方式是正常的disable掉thinking mode
🍀 LuckyJohn💫 af:~/ $ curl http://localhost:11434/api/chat \ [12:05:38]
-d '{
"model": "qwen3.5:9b",
"messages": [{"role": "user", "content": "tell me a joke"}],
"options": {
"stop": ["<thought>", "</thought>"],
"temperature": 0.7
},
"think": false,
"stream": false
}'
{"model":"qwen3.5:9b","created_at":"2026-03-05T04:08:27.629941Z","message":{"role":"assistant","content":"Why don't scientists trust atoms?\n\nBecause they **make up everything**! 🤓⚛️"},"done":true,"done_reason":"stop","total_duration":2170299292,"load_duration":123259625,"prompt_eval_count":16,"prompt_eval_duration":351902542,"eval_count":23,"eval_duration":1670221332}% 🍀 LuckyJohn💫 af:~/ $另外，可以让claude code配合ollama一起使用：
ANTHROPIC_BASE_URL="http://localhost:11434" ANTHROPIC_AUTH_TOKEN="ollama" claude --model qwen3.5:9b NOTE
使用最新版的
ollama launch claude --model qwen3.5:9b命令一键启动也可以，背后的机制相当于是先ollama run启动服务之后，再启动claude code。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
