MCP
做 MCP 相关项目时，经常会遇到几个词： MCP JSON-RPC Transport stdio SSE Streamable HTTP 这些词经常一起出现，如果不把层次拆开，很容易混在一起。 这篇文章尝试从工程开发的角度，把它们之间的关系梳理清楚。重点不是翻译标准文档，而是建立一套比较稳定的理解模型。 一、先分清三层：MCP、JSON-RPC、Transport 可以先记住这句话： MCP 负责：Agent 能调用什么能力 JSON-RPC 负责：调用消息长什么样 Transport 负责：消息怎么传过去 也就是： MCP = 协议语义层 JSON-RPC = 消息格式层 Transport = 传输层 更直观一点： MCP： 我要调用工具、读取资源、获取 prompt JSON-RPC： method 是什么，
MCP
一次从"会用"到"理解原理"再到"能优化"的完整探索记录。 本文记录了我通过实际动手连接一个远程 MCP 服务（SIF —— 亚马逊卖家流量分析平台），一步步深入理解 MCP 协议机制、LLM 上下文管理、注意力资源分配、以及工具编排优化方案的全过程。 一、起点：连上一个真实的 MCP 服务 什么是 MCP？ MCP（Model Context Protocol）是 Anthropic 主导设计的一个开放协议，目的是标准化 AI 应用与外部工具/数据源之间的通信方式。你可以把它理解为"AI 世界的 USB 接口"
agent
1. 我当前面对的现实约束 虽然我现在越来越倾向于： * 上层做 Agent * 下层做 Harness 但现实里调用我的人，很多时候只会通过 API 的形式来调用能力。 这意味着： * 我未必能决定上层最终长成什么样 * 外部接入形式可能仍然是 HTTP、函数调用或者一次性接口 2. 我当前的重要判断 我现在认为，这并不和 Agent + Harness 的方向冲突。 更合理的理解是： * Agent + Harness 是内部核心结构 * API、函数调用、HTTP 等形式是外部兼容层 也就是说，我真正需要先做好的是： * Agent 的能力设计 * Harness 的抽象与落地 * Agent 和 Harness 之间的接口关系 而不是一开始就被外部接入形式绑死。 3. 一个重要认识：不是 API 和 Agent 二选一 我当前更认可的分层是：
agent
1. 我目前开始形成的一个工作判断 我觉得之后我的工作可以分成两个主要方向。 方向一：构建一个聪明且通用的 Agent 这个 Agent 的重点，不是把所有具体业务逻辑都写死在内部，而是让它擅长： * 理解任务 * 选择工具 * 读取状态 * 逐步决策 * 失败后调整 * 结合 Skill 和结构化输出来完成多步编排 也就是说，它更像是一个通用的编排和判断层。 方向二：把具体业务需求落成 Agent-Friendly Harness 当一个具体业务需求到来时，我不再优先想着： * 直接暴露零散 API * 直接写一个固定 workflow 而是优先考虑： * 能不能把这类业务能力整理成命令树 * 能不能有清晰的状态模型 * 能不能有结构化输出 * 能不能让 Agent 更容易识别这些能力并自主组合 也就是说，重点从“写固定流程”转向“设计能力接口”。 2. 一个重要修正：不是不要 API，而是不要把 API 直接等同于
agent
1. 我当前对这个项目最核心的一个判断 我现在越来越觉得，这个项目的核心是 agent-first。 也就是说，它是先站在“未来软件能力会越来越需要被 Agent 调用”的前提出发，再反过来思考： * 接口应该长什么样 * 能力该如何暴露 * 什么样的形式最适合 Agent 理解和调用 在这个前提下，CLI 形式的 harness 就变成了一种非常现实的工程落地方式。 2. 为什么它不把流程写死 我当前的一个重要理解是： 这个项目不想做固定工作流系统。 它更希望做的是： * 把领域能力整理成结构化命令树 * 把这些能力作为一组可组合的工具暴露出来 * 把具体任务编排尽量交给 Agent 自己决定 所以它信任 Agent 的地方在于： * 让 Agent 去选命令 * 让 Agent 去组合步骤 * 让 Agent 去形成任务级流程 3. 但这不是“少设计” 这一点是我现在特别明确的一个修正。 不能把这个项目理解成： * 因为相信
agent
1. 我当前最强烈的一个感受 不同 Agent、不同底层模型，对同一套 CLI 的理解能力并不一样。 这意味着： * 同样一个 harness * 不同 Agent 的使用效果可能差很多 所以真正重要的不只是“有没有这些命令”，而是： 这些能力是如何暴露给 Agent 的。 2. 我目前理解到的关键点 这个项目不是简单把旧软件的功能堆成一堆命令，而是在思考： * 怎么让 Agent 更容易理解工具能力 * 怎么让 Agent 在面对真实任务时更容易选对命令 * 怎么降低不同模型之间的理解差异带来的问题 也就是说，命令设计、文档、Skill、JSON 输出，这些都不是附属物，而是能力暴露设计的一部分。 3. 我目前觉得这个项目最精髓的地方 它没有把任务流程完全写死。 它做的是： * 提供一棵结构化的能力树 * 让 Agent 根据真实需求去决定调用哪几个命令 * 让 Agent 自己把这些命令组合成实际工作过程
agent
1. 为什么我在这一部分容易混乱 因为一个 harness 目录里通常会同时出现： * 设计文档 * README * Skill * CLI 入口 * core 业务模块 * utils 后端桥接 * tests 如果不先按职责区分，很容易把这些文件都看成“某种说明文档”或者“某种脚本入口”。 2. 一个标准 harness 的结构 我目前可以把一个标准 harness 粗略理解成： <software>/ └── agent-harness/ ├── <SOFTWARE>.md ├── setup.py └── cli_anything/ └── <software>/ ├── __main__.py ├── README.md ├── <software>_cli.
agent
1. Agent 和 harness 的边界 这是我在理解过程中非常关键的一点。 当前我的理解： * Agent 负责“决定做什么” * Harness 负责“把事情做成可调用能力” 也就是说： * Agent 更像策略层、决策层、编排层 * Harness 更像能力层、执行层、适配层 Harness 本身不是 Agent，它更像是 Agent 可调用的工具系统。 2. 这个项目的反馈机制属于哪一类 我之前会自然想到“自我反思型”的 harness： * 会自动评估自己做得好不好 * 会自动调整策略 * 会自动重规划 但这个项目里的 harness 并不强内建这种运行时自我反思。 它更强的是： * 可观察：info、list、status、history * 可验证：真实输出检查、E2E 测试、
agent
1. 为什么我会觉得这个项目里的 harness 有点奇怪 因为我之前接触过的 harness，更像是： * 一个黑盒环境 * 给 LLM 设定边界和工具 * 让 LLM 在里面自己探索、执行、达成目标 而这个项目里的 harness 明显不是这个意思。 2. 这个项目里的 harness 是什么 当前我的理解： 这里的 harness 更像是“站在 Agent 视角，为某个具体软件搭建的一整套能力接入系统”。 它不只是一个脚本，也不只是一个 CLI 文件，而是通常包含： * CLI 入口 * core 业务模块 * backend 真实软件适配 * session 状态管理 * tests * README * TEST.md * SKILL.md
agent
1. 我最开始看到的现象 这个仓库根目录下有很多不同的软件目录，例如： * gimp/ * blender/ * libreoffice/ * drawio/ * zotero/ 所以它不是单一应用，而是一个多软件、多 harness 的总仓库。 2. 项目在做什么 我目前的理解： CLI-Anything 想把原本主要通过 GUI 使用的软件，整理成 Agent 也能稳定调用的 CLI 接口。 它不是简单做几个命令，而是在做一套标准化的软件能力接入方案。 3. 这里的 CLI 到底是什么意思 我一开始容易把 CLI 理解成“黑框里的自由互动”。 后面逐渐明确： * 终端/黑框：只是运行环境 * CLI：是能力暴露出来的命令接口 * 脚本：是实现 CLI 的一种方式 所以这里的 CLI 更接近“面向终端的函数调用接口”
agent
这篇写什么 补齐主链路之外的包：tui、web-ui、mom、pods。它们不是前两层核心抽象，但决定了这套体系如何被真正使用、展示和部署。 快速定位 * tui：终端 UI 引擎（输入、渲染、选择器、弹层等体验基础设施） * web-ui：Web 场景的 chat/agent UI 组件库 * mom：Slack 里的 agent bot 产品 * pods：远程 GPU pod 上的模型部署与运行管理 packages/tui 它不参与模型调用和 agent loop，但决定 terminal 产品是否“像一个真正应用”而不是 stdout 脚本。 packages/web-ui
agent
这篇写什么 把两份偏方法论的笔记（主 Agent 设计、Tools 设计）合并成一篇：给出一套可迁移、可施工的 agent 产品设计方法，不依赖编程场景。 主 Agent：先设计任务闭环，不要先写 prompt 主 agent 不是“一个大 prompt”，而是：任务边界、角色定义、行为规则与闭环运行方式的组合。 一个可用的主 agent，首先要回答： * 核心目标是什么 * 完成标准是什么 * 默认怎么推进 * 何时继续、何时停止 * 遇到失败怎么处理 提示词只是这些设计的表达载体，不是起点。 主 Agent 的设计骨架（建议写清楚） * 目标定义 * 输入定义（用户通常怎么提任务） * 输出定义（你最终返回什么形态） * 完成条件与停止条件 * 默认策略（模糊时问还是猜、
陕公网安备61011302002223号