一次千赞项目的 pr
无心插柳 柳成荫，只是测试一下使用，觉得它的项目缺少本地测试的前端页面，vibe了一个 就给提交了，没想到被 merge了
Read more
MCP 服务端的隐藏设计：结论性数据如何改变
Agent 的工作方式 我们以为 MCP 服务只是查数据的管道，拆开一看，发现服务端已经把分析结论都算好了。这个发现改变了我对 Agent 架构的理解。 起因：一次对 MCP 服务的逆向探索 最近在研究 MCP（Model Context Protocol）的实际应用，我选了一个真实的商业 MCP 服务 —— 某电商卖家流量分析平台作为研究对象。该服务提供了 27 个工具，覆盖关键词分析、流量运营、广告洞察等领域。 最初的预期很简单：MCP 服务就是一个数据接口，Agent（LLM）调用它拿到原始数据，然后自己分析、得出结论、给用户建议。 实际拆开一看，完全不是这么回事。 第一个发现：返回数据里藏着完整的分析结论 我写了一个 Python 脚本，绕过所有 AI 客户端，直接用
FastAPI 异步任务服务的并发设计演进：从单进程轮询到多 Worker 协程直处理
本文记录了一个 FastAPI 异步任务服务在并发架构上的思考和演进过程。这个服务的本质很简单：接收客户端请求，转发给下游 AI API，把结果存起来供客户端轮询。它不做复杂的业务计算，不做数据聚合，就是一个纯转发层——接活、派活、存结果。正因为场景足够简单，我们才有机会做一次化繁为简的架构妥协，把原本"看起来该用任务队列"的设计砍到只剩三行核心配置。 一、先说清楚场景：我们到底在干什么 这个服务做的事情可以用一句话概括： 客户端提交参数 → 服务转发给下游 AI API → 等结果 → 存 Redis → 客户端来取。 关键特征： * 纯 IO 转发：服务本身不做任何 CPU 密集计算，所有耗时都花在等下游 API 返回。一次调用几秒到几十秒不等，全是网络等待。 * 异步模式：客户端提交任务后立即拿到 task_id，
从连上一个 MCP 服务到理解 AI 系统的工程本质
一次从"会用"到"理解原理"再到"能优化"的完整探索记录。 本文记录了我通过实际动手连接一个远程 MCP 服务（SIF —— 亚马逊卖家流量分析平台），一步步深入理解 MCP 协议机制、LLM 上下文管理、注意力资源分配、以及工具编排优化方案的全过程。 一、起点：连上一个真实的 MCP 服务 什么是 MCP？ MCP（Model Context Protocol）是 Anthropic 主导设计的一个开放协议，目的是标准化 AI 应用与外部工具/数据源之间的通信方式。你可以把它理解为"AI 世界的 USB 接口"
OpenCLI 学习 08：现实约束与兼容层思路
1. 我当前面对的现实约束 虽然我现在越来越倾向于： * 上层做 Agent * 下层做 Harness 但现实里调用我的人，很多时候只会通过 API 的形式来调用能力。 这意味着： * 我未必能决定上层最终长成什么样 * 外部接入形式可能仍然是 HTTP、函数调用或者一次性接口 2. 我当前的重要判断 我现在认为，这并不和 Agent + Harness 的方向冲突。 更合理的理解是： * Agent + Harness 是内部核心结构 * API、函数调用、HTTP 等形式是外部兼容层 也就是说，我真正需要先做好的是： * Agent 的能力设计 * Harness 的抽象与落地 * Agent 和 Harness 之间的接口关系 而不是一开始就被外部接入形式绑死。 3. 一个重要认识：不是 API 和 Agent 二选一 我当前更认可的分层是：
陕公网安备61011302002223号