agent
0. 一句话点破本质 **让"等"发生在便宜的子进程里,让贵的 agent 只在有事时醒。**心跳解决"最迟多久必有人查岗",探针解决"事情一发生几乎立刻有人到场"——两个机制回答的是两个不同的问题,谁也替代不了谁。 1. 机制全貌:会自杀的轮询进程 + 宿主的"尸体通知" 我的实现只有两块积木: 积木一:一个有明确死法的后台循环 # 放行任务的同时,后台挂上(run_in_background) for i in $(seq 1 20); do 信号=$(ssh data "tmux capture-pane -t dna
agent
0. 一句话点破本质 **心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。 1. 第一性原理:为什么"醒来知道干啥"这么难 一个长期任务里的 agent 面临三重失忆: 1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述 2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期 3. 任务本身会变—
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 更接近“面向终端的函数调用接口”
陕公网安备61011302002223号