二哥的Java进阶之路

沉默王二约 14125 字大约 47 分钟

01、简历上为什么都在写 AI 相关的内容？

老王翻着我的简历：“我看你简历上全是 AI 项目，有派聪明 RAG，有 PaiFlow Agent，传统开发经验怎么没写？”

我说：“王哥，不是我不写，是我觉得 AI 相关的内容更能体现我的竞争力。”

“传统开发我会，Java、Spring Boot、MyBatis 这些八股你随便问，没有我背不出来的，哦不，没有我回答不上来的。但现在是什么时代？AI 时代。HR 和你们这些面试官看简历，第一眼想看的不就是有没有 AI 开发经验？”

“再说了，AI 开发不是空中楼阁，底层还是传统开发。RAG 系统要用向量数据库，得懂 ElasticSearch；Agent 要调用 API，得懂 HTTP 或者 MCP 协议；工作流要编排任务，得懂并发编程、消息队列。”

老王追问：“那你觉得传统后端开发和 AI 应用开发最大的区别是什么？”

我说：“最大的区别是思维方式。”

“传统开发是确定性思维，输入确定，输出确定，逻辑是线性的。AI 开发是概率性思维，输入确定，输出不确定，逻辑是概率的。”

“比如传统开发，你写个 if-else，条件满足就走 A 分支，不满足就走 B 分支，结果是确定的。”

“AI 应用开发不一样，你给模型一个 prompt，它可能给你 A 答案，也可能给你 B 答案，甚至给你 C 答案。你要设计的是怎么让模型大概率给你想要的答案，而不是 100%确定。”

“这种思维方式的转变，是很多传统开发转 AI 开发最难适应的地方。”

01-1、AI 运维智能管理平台是一个什么平台？

我说：“这是我最近做的一个项目，用 AI 来辅助运维工作。”

“平台核心功能包括：

日志分析：自动分析系统日志，识别异常模式，提前预警。

故障诊断：出现故障时，自动收集相关信息，给出可能的原因和解决方案。

资源优化：分析服务器资源使用情况，给出优化建议，比如哪些服务可以缩容、哪些需要扩容。

知识库问答：把运维文档、历史 case 都录入知识库，运维同学可以直接问 AI，不用翻文档。”

老王问：“这个平台用了什么技术？”

我说：“底层是 RAG+Agent 的技术栈，上层用 LangGraph4j 做了工作流编排。”

02、什么是 AI Agent？

考察点：Agent 概念

参考答案：

普通的 LLM 调用就是一问一答：你给它一个问题，它给你一个回答，完事。

AI Agent 是让大模型能够自主行动：它不只是回答问题，还能规划任务、使用工具、循环思考，直到完成目标。

从技术上说，Agent 比普通 LLM 多了几个核心能力：

第一是工具调用。Agent 能使用外部工具，比如搜索引擎、数据库、API。LLM 本身只会生成文本，但 Agent 框架会解析 LLM 的输出，识别出它想调用某个工具，然后真的去调用，把结果再喂回给 LLM。这就是 Function Calling。

第二是规划能力。面对一个复杂任务，Agent 会把它拆解成多个步骤，然后一步步执行。比如生成播客，它会规划：先理解用户给的主题 → 生成对话脚本 → 调用 TTS 合成语音 → 拼接音频。这个过程不是一次 LLM 调用能完成的，需要多轮交互和决策。

第三是记忆。普通 LLM 调用是无状态的，上一轮对话说了什么，下一轮它就忘了（除非你把历史都塞进 prompt）。Agent 可以有短期记忆（当前任务的上下文）和长期记忆（跨任务的知识积累），这让它能处理更复杂的场景。

第四是自主循环。Agent 不是调一次就结束，它会根据执行结果来决定下一步做什么。调用工具失败了，可能会换个方式重试；发现信息不够，可能会去搜索更多资料。这种感知-决策-行动的循环，是 Agent 的核心特征。

回到 PaiFlow，我们的工作流引擎其实就是一种 Agent 的实现方式。用户通过可视化界面编排一个工作流，里面有 LLM 节点、工具节点、条件分支，这本质上就是在定义一个 Agent 的"行为逻辑"。工作流引擎负责调度执行，就相当于 Agent 的"大脑"在驱动整个流程。

比如播客生成这个场景：用户输入一个主题，工作流先调 LLM 节点生成脚本，再调 TTS 工具节点合成语音，中间还有条件判断（内容是否合规）。这整个流程就是一个 Agent 在工作——它理解了用户意图，规划了执行步骤，调用了外部工具，最终完成了任务。

所以简单总结：LLM 是大脑，Agent 是有手有脚、能干活的完整个体。PaiFlow 做的事情，就是让用户能方便地组装出这样一个能干活的 Agent。

03、Function Calling 是什么？

考察点：工具调用

参考答案：

Function Calling 是让大模型能够调用外部函数/API 的能力。

普通的 LLM 只能输出文本，你问它帮我查一下今天北京的天气，它最多回你好的，我帮你查一下——但它真的查不了，因为它没有手。Function Calling 的作用就是让 LLM 能说出它想调用哪个工具、传什么参数，然后由外部框架去真正执行。

整个流程是这样的：

第一步，告诉 LLM 有哪些工具可用。调用 LLM 的时候，除了传 prompt，还会传一个 tools 列表，每个工具有名字、描述和参数定义。比如：

{
  "name": "get_weather",
  "description": "查询指定城市的天气信息",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名称"}
    },
    "required": ["city"]
  }
}

第二步，LLM 决定要不要用工具。用户问今天北京天气怎么样，LLM 看到有个叫 get_weather 的工具，描述是查询指定城市的天气信息，它就明白了——这个工具能帮我回答这个问题。然后它输出一个结构化的调用请求：

{
  "tool_calls": [{
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"北京\"}"
    }
  }]
}

第三步，框架执行工具，把结果喂回 LLM。外部框架解析这个输出，真的去调天气 API，拿到结果后再塞回对话里，LLM 根据结果生成最终回答。

04、MCP 是什么？

考察点：MCP 协议

参考答案：

MCP 是 Anthropic 提出的模型上下文协议，目的是标准化大模型和外部工具的交互方式。

以前每个工具都要单独对接，写一堆适配代码。MCP 定义了统一的协议，工具实现 MCP Server，应用实现 MCP Client，就能互联互通。

MCP 的核心概念有三个：

Resources：只读数据源（文件、数据库）
Tools：可执行的功能（API 调用、代码执行）
Prompts：预定义的提示词模板

通信方式有两种：

stdio：通过标准输入输出通信，适合本地工具
SSE：通过 HTTP SSE 通信，适合远程服务

我们的 MCP Client 实现思路是这样：

public class McpClient {
    private final String transport;  // "stdio" or "sse"

    // 发现可用工具
    public List listTools() {
        return sendRequest("tools/list");
    }

    // 调用工具
    public Object callTool(String name, Map args) {
        return sendRequest("tools/call", Map.of("name", name, "arguments", args));
    }

    private Object sendRequest(String method, Object params) {
        if ("stdio".equals(transport)) {
            // 写入子进程的 stdin，从 stdout 读取结果
        } else {
            // 发送 HTTP 请求
        }
    }
}

通过配置化方式接入 MCP 工具：

mcp_servers:
- name: "filesystem"
transport: "stdio"
command: ["python", "filesystem_server.py"]
- name: "search"
transport: "sse"
url: "http://search-mcp:8080"

追问 1：Function Calling 和 MCP 什么区别？

参考答案：

FunctionCall：函数调用，它允许 LLM 根据用户的自然语言输入识别它需要什么工具以及格式化的工具调用的能力；

MCP：提供了一个通用的协议框架来发现、定义、以及调用外部系统提供的工具能力；

06、什么是 RAG？

我说：“RAG，是 Retrieval-Augmented Generation 的缩写，也就是检索增强生成。”

“简单说，就是让大模型在回答问题之前，先去知识库里检索相关信息，然后把检索结果作为上下文，一起送给大模型生成回答。”

“这样做有两个好处：

一是解决大模型的知识截止问题。大模型的训练数据有截止日期，之后发生的事情它不知道。RAG 通过实时检索，可以获取最新信息。

二是解决大模型的幻觉问题。大模型有时候会一本正经地胡说八道。RAG 通过检索真实文档，让回答有据可依。”

老王追问：“RAG 的核心流程是什么？”

我说：“四步走：

第一步，文档预处理。把原始文档切分成 chunk，用 embedding 模型转成向量，存入向量数据库。

第二步，查询向量化。用户提问时，把问题也转成向量。

第三步，向量检索。在向量数据库里找最相似的 chunk。

第四步，增强生成。把检索到的 chunk 作为上下文，和问题一起送给大模型，生成最终回答。”

老王追问：“RAG 和微调有什么区别？什么时候用 RAG，什么时候用微调？”

我说：“这是个好问题，很多人搞混。”

“RAG 是检索增强，不改变模型本身，只是给模型提供额外的上下文。适合知识频繁更新、需要实时性的场景。”

“微调是改变模型参数，让模型学会新的知识。适合知识相对稳定、需要深度理解的场景。”

“我的判断标准是：如果知识更新频率高于一周，用 RAG；如果低于一周，可以考虑微调。”

“另外，RAG 成本低，不需要训练；微调成本高，需要标注数据和算力。”

老王点点头：“判断标准清晰。那你做的 RAG 智能报价系统是在哪个公司？”

06-1、RAG 智能报价系统是在哪个公司做的？

我说：“是在上一家公司，一家做 B2B 供应链的企业。”

“他们的业务场景是：采购商在平台上传需求文档，系统需要根据文档内容，自动生成报价方案。”

“传统做法是人工看文档、人工写报价，一个单子平均要 2 小时。用 RAG 之后，系统自动解析文档、匹配历史报价、生成报价方案，平均 5 分钟搞定。”

老王追问：“技术上有哪些难点？”

我说：“三个难点。”

“第一，文档格式复杂。采购商上传的文档有 PDF、Word、Excel，还有图片。我们用了 OCR+文档解析，先把各种格式转成文本，再做后续处理。”

“第二，chunk 切分策略。切得太细，语义不完整；切得太粗，检索不精准。我们试了多种策略，最终按段落切分，效果比较好。”

“第三，检索结果重排。向量检索返回的结果，相关性不一定是最高的。我们加了重排模型，对检索结果二次排序，准确率提升了 15%。”

老王眼睛一亮：“不错，技术细节也讲清楚了。那你在这个项目里担任什么角色？”

06-2、你在 RAG 项目中担任什么角色？

我说：“我是技术负责人，带了一个 5 人的小团队。”

“具体工作包括：

技术选型：调研了 Milvus、Pinecone、Weaviate、ElasticSearch 等向量数据库，最终选了 ElasticSearch，因为性能好、社区活跃。

架构设计：设计了文档预处理服务、向量检索服务、报价生成服务三个核心模块。

模型调优：针对报价场景，微调了 embedding 模型，让检索准确率从 75%提升到 92%。

工程落地：解决了文档格式兼容、chunk 切分策略、检索结果重排等工程问题。”

老王追问：“安装包这些东西都是你整理的还是协助的？”

06-3、派聪明RAG这些安装包都是你整理的还是协助的？

我说：“安装包是我主导整理的。”

“因为 RAG 系统涉及多个组件：向量数据库、embedding 服务、大模型 API、业务后端。部署起来很麻烦，我整理了一键安装包，把 Docker Compose 配置、环境变量模板、初始化脚本都打包进去。”

“新环境部署，原来需要一天，现在半小时搞定。”

老王问：“镜像打包是开发打包还是你负责？”

06-4、派聪明RAG的镜像打包是开发打包还是你负责？

我说：“CI/CD 流程是我搭建的，但镜像打包是自动化的。”

“我用 GitLab CI 做了流水线：代码提交 → 自动测试 → 构建镜像 → 推送仓库 → 触发部署。开发人员只需要写代码，打包部署全是自动的。”

“镜像分层也做了优化，基础镜像和业务镜像分开，构建时间从 10 分钟降到 3 分钟。”

“另外，镜像安全扫描也做了。用 Trivy 扫描镜像漏洞，高危漏洞自动阻断发布。”

老王追问：“如果镜像构建失败，怎么排查？”

我说：“先看构建日志，定位失败步骤。常见原因有：依赖下载失败、单元测试不通过、Dockerfile 语法错误。”

“如果是依赖下载失败，检查网络或者换国内镜像源。如果是测试不通过，本地先跑通再提交。如果是 Dockerfile 错误，用 docker build --progress=plain 看详细日志。”

老王点点头：“工程化能力不错。那 AI 运维智能管理平台是一个什么平台？”

07、token是什么？

Token 不是字，不是词，也不是句子。它是大模型处理信息的最小单元。你可以把它理解成大模型的“像素”，就像图片由像素组成，大模型眼里的世界由 Token 组成。

中文 1 个汉字约等于 1.5-2 个 Token，英文 1 个单词约等于 1-1.5 个 Token。所以同样一段话，中文比英文更“费 Token”。

一次普通的 AI 对话，输入加输出大概消耗 1000-3000 个 Token。

如果是 Coding 场景，让 AI 帮你读一个中等规模的代码仓库再做修改，一次对话消耗 5 万到 20 万 Token 是常事。像 Claude Code 这种 Agent 模式，一个复杂任务跑下来，烧掉 50 万 Token 都不稀奇。

所以你就能理解，为什么很多人用 AI 写代码写到一半，突然收到“余额不足”的提示，不是你用得多，是 Coding 场景本身就是 Token 黑洞。

就在刚刚，一个挺有意思的事情发生了：国家数据局首次给了 Token 一个官方中文名，叫词元。意思是“语言处理领域中，最小的、不可再分的基础信息单位”。这个命名延续了“像素”“字节”的构词逻辑，“词”锚定语言处理范畴，“元”代表最小基本单元。

清华大学的杨斌教授在两会期间曾提了个新方案：模元。理由是“模”直接对应大模型、多模态，锚定 AI 场景的核心属性。

在我看来，日常使用中，大家直接说 Token 就行。

但这个道理得明白，上一个时代的基础计量单位是 bit，这个时代的基础计量单位就是 Token。

07-1、你一天能烧多少 token？

老王：“你一天能烧多少 token？”

我说：“王哥，就几十个吧。”

一看老王的脸色不太好看，我立马就改口了：“逗逗你的呀，王哥。我订阅了各种 Coding Plan，尤其是 Qoder，我订阅的是 6000 Credits 那个，一个月都不太够用。”

我接着说：“我昨天刚上架了派聪明 RAG 系统，发现 token 的消耗就有点顶不住。”

老王追问：“那你怎么优化 token 消耗？”

我说：“几个思路，我详细讲讲。”

“第一，prompt 压缩。很多 prompt 里都有冗余信息，比如重复的指令、不必要的示例。我在派聪明 RAG 中写了一个压缩算法，能自动识别并去除这些冗余。”

“第二，缓存机制。相同的问题，如果上下文没变，直接返回缓存结果，不再调用模型。”

“第三，模型分级。简单任务用轻量级模型，比如 Qwen-Turbo，速度快、成本低。复杂任务才用大模型，比如 GPT-5.4。”

“第四，批量处理。多个相似的问题，合并成一次调用，减少 API 请求次数。”

老王听完眼睛一亮：“批量处理这个思路不错，具体怎么实现的？”

我说：“用消息队列做缓冲。用户的问题先入队列，然后按时间窗口聚合，比如 100ms 内的相似问题合并成一次批量请求。这样 API 调用次数能减少 70%。”

老王点点头：“有成本意识，还懂工程优化，不错。”

08、LangGraph4j是什么？

“LangGraph4j 是一个 Java 的工作流编排框架，特别适合做 AI 任务的工作流。”

“比如故障诊断这个场景，工作流可以这么设计：

第一步，接收告警通知；第二步，查询相关日志；第三步，分析日志内容；第四步，查询知识库；第五步，生成诊断报告；第六步，通知运维人员。”

“每个步骤都是一个节点，节点之间可以设置条件分支。比如如果日志分析发现是磁盘满了，直接走磁盘清理分支；如果是内存溢出，走服务重启分支。”

09、平常开发用 AI 工具多吗？

我说：“多，现在基本离不开 AI 工具了。”

“搭项目骨架的时候，我会用 Qoder 的 Quest 模式；读源码我会用 TRAE 的 Gemini；开发任务我会交给 Codex。”

“但用得最多的还是 Claude Code。”

老王追问：“请讲一下你在 AI 编程中的使用经验，比如 Claude Code。”

09-1、请讲一下你在 AI 编程中的使用经验，比如 Claude Code。

我说：“Claude Code 是我目前的主力开发工具。”

“我用它做过几件事：

一是代码重构。给一个指令，它能自动理解代码逻辑，给出重构方案，甚至直接生成重构后的代码。

二是 Bug 修复。把报错信息丢给它，它能分析可能的原因，给出修复建议。有时候甚至能直接定位到问题代码。

三是代码生成。写重复性的代码特别快，比如 CRUD 接口、单元测试，几分钟就能生成一套。

四是技术调研。遇到不熟悉的技术，直接问它，比查文档快多了。”

老王问：“Claude Code 和传统的 IDE 插件有什么区别？”

我说：“传统插件是辅助，Claude Code 是协作。”

“传统插件只能做代码补全、语法检查这些基础功能。Claude Code 能理解你的意图，参与整个开发流程。”

“比如你说‘/github-skill-forge 找 GitHub 上有没有辅助写小说的项目’，它能按照某个 Skills 帮我找出来我想要的源码，然后下载到本地后进行快速的二次开发。”

老王点点头：“最近很火的 OpenClaw 了解过吗？”

10、最近很火的 OpenClaw 了解过吗？

我说：“太了解了，我自己部署了好几个 Agent。”

“OpenClaw 是一个 Agent 框架，让你可以用自然语言指挥 AI 完成复杂任务。”

“我自己部署了三个 Agent：一个是 gitcode 账号审核助手，一个是技术文档生成助手，还有一个是定时任务监控助手。”

“比如 gitcode 审核这个场景，以前我要手动登录后台、搜索用户、添加权限，一个账号要 2 分钟。现在我把流程教给 Agent，它在后台自动执行，20 个账号 1 分钟搞定。”

老王眼睛一亮：“效率提升很明显啊。那如果让你设计一个 Agent，它的长短期记忆你打算怎么设计？”

10-1、如果让你设计一个 Agent，它的长短期记忆你打算怎么设计？

我说：“我会设计两层记忆：短期记忆和长期记忆。”

“短期记忆，Session，存储当前对话的上下文。包括用户输入、Agent 回复、工具调用结果。短期记忆在内存中，对话结束就清空。”

“长期记忆，Memory，存储跨对话的重要信息。比如用户偏好、历史结论、关键事实。长期记忆持久化到磁盘，下次对话可以读取。”

“两者的协作方式是：对话过程中，Agent 实时更新短期记忆；当短期记忆接近 Context 上限时，触发 Compaction，把重要信息写入长期记忆；新对话开始时，从长期记忆中检索相关信息，加载到上下文中。”

“具体实现上，短期记忆存在内存里，用链表结构，方便快速插入和删除。长期记忆存在磁盘上，用向量数据库，方便语义检索。”

“还有一个细节：不是所有信息都值得写入长期记忆。Agent 会评估信息的重要性，只有重要程度超过阈值的才会写入。评估标准包括：用户明确陈述的事实、对话的关键结论、可能影响后续决策的信息。”

老王追问：“OpenClaw 的核心组件有哪些？”

10-2、OpenClaw 的核心组件有哪些？

我说：“五个核心组件：”

“LLM，大语言模型，Agent 的大脑，负责理解指令、规划任务、生成回复。”

“Task Planner，任务规划器，把用户需求拆解成可执行的任务步骤。”

“Tool Executor，工具执行器，负责调用外部工具，比如搜索、文件操作。”

“Memory Manager，记忆管理器，管理短期记忆和长期记忆。”

“Skill Loader，技能加载器，动态加载 Skills，扩展 Agent 能力。”

“这五个组件之间通过消息总线通信，互相解耦。比如你可以把 LLM 从 Claude 换成 GPT，其他组件感知不到变化。”

“另外，OpenClaw 还有 8 个配置文件，定义 Agent 的完整人格。AGENTS.md 定义能力边界，SOUL.md 注入灵魂，TOOLS.json 划定禁区，SKILLS.json 配置技能，MEMORY.json 管理记忆，SESSION.json 管理会话，ROUTER.json 配置路由，CONFIG.json 其他配置。”

老王问：“Agent 是常驻进程吗？”

10-3、Agent 是常驻进程吗？

我说：“不是，Agent 是 per-session 的瞬态实例。”

“每个对话都是一次完整的加载-执行-销毁循环。用户发起对话时，Agent 加载配置、初始化记忆；对话过程中，Agent 执行任务；对话结束，Agent 保存状态、释放资源。”

“这种设计的好处是资源节省，Agent 不用一直占用内存；配置实时生效，每次 run 都会重新读取配置文件。”

“还有一个好处是隔离性。每个对话都是独立的 Agent 实例，一个对话出问题不会影响其他对话。”

老王追问：“Session 太长，会不会挤爆 LLM 的 Context？”

10-4、Session 太长，会不会挤爆 LLM 的 Context？

我说：“会，所以 OpenClaw 做了优化。”

“两个机制：Compaction 和 Pruning。”

“Compaction，压缩，当 Session 接近 Context 上限时，Agent 把重要信息写入 Memory，然后压缩 Session 内容。”

“Pruning，修剪，在发送给 LLM 之前，临时裁剪旧的 tool 结果。比如搜索返回 100 条结果，但 LLM 只需要前 10 条，后面的就剪掉。”

“Compaction 是持久化的，重要信息会长期保存。Pruning 是临时的，只影响当前请求。”

“具体数值上，当 Session 长度超过 4000 个 token 时，触发 Compaction。Pruning 会保留最近 2000 个 token，裁剪更早的内容。”

“还有一个优化：如果某个 tool 调用结果特别大，比如搜索返回了 1000 条结果，Pruning 会直接取前 10 条，其他的全部丢弃。”

老王点点头：“Memory 机制是怎么设计的？”

10-5、Memory 机制是怎么设计的？

我说：“Memory 机制分三个阶段：写入、存储、读取。”

“写入阶段，Agent 分析 Session 内容，提取重要信息，包括用户明确陈述的事实、对话中的重要结论、Agent 生成的有价值信息。”

“存储阶段，写入的 Memory 存到 memory.jsonl 文件，每条 Memory 包含 content、timestamp、importance、tags。”

“读取阶段，新对话开始时，根据当前对话内容，检索相关的 Memory。检索策略包括关键词匹配、语义相似度、时间衰减。”

“关键词匹配就是简单的字符串匹配，适合检索明确的实体，比如用户名、项目名称。”

“语义相似度用向量检索，把查询和 Memory 都转成向量，计算相似度。这个适合检索概念相关的内容，比如‘分布式事务’和‘分布式一致性’，虽然关键词不同，但语义相关。”

“时间衰减是给 Memory 加时间权重，越新的 Memory 优先级越高。但也不是简单的线性衰减，而是指数衰减，保证最新的几条 Memory 权重明显高于旧的。”

“为了避免 Memory 爆炸，还有几个优化策略：重要性评分，只保留高重要性的 Memory；定期清理，默认保留 30 天；合并相似 Memory，避免重复；分层存储，高频放内存，低频放磁盘。”

“重要性评分是 Agent 在写入 Memory 时自动评估的，评估标准包括：信息的新颖性、对后续决策的影响程度、用户的明确强调。”

老王追问：“如果让你优化 OpenClaw 的 Memory 机制，你会怎么做？”

我说：“有几个优化方向。”

“第一，引入记忆遗忘机制。人脑会遗忘不重要的信息，Agent 也应该有类似机制。可以设计一个遗忘曲线，重要性低的信息遗忘得更快。”

“第二，支持记忆关联。现在的 Memory 是独立的，如果能支持 Memory 之间的关联，比如‘这个项目用了 Spring Boot’和‘Spring Boot 是 Java 框架’关联起来，检索效果会更好。”

“第三，分层记忆。短期记忆、中期记忆、长期记忆三层，每层有不同的存储策略和检索策略。”

11、CLI 是什么

“最近飞书、网易云音乐都在发 CLI 工具，你怎么看这波热潮？”老王笑嘻嘻地问，“AI 圈每天都在出新东西，有些是风口，有些是泡沫。CLI 这波，你觉得是哪个？”

能感受到，老王对 AI 时代的技术敏感度是真的高。

飞书也不愧是 OpenClaw 大火之后的最大赢家，不仅第一时间降低飞书的配置难度，还在第一时间做出针对 Agent 的 CLI，成为我和 AI 交流最频繁的 IM 工具。

我说：“王哥，这波不是泡沫，是 AI Agent 时代的基础设施升级。”

老王眼睛一亮：“哦？说说看。”

01、CLI 到底是个啥？

“王哥，我先问你一个问题，你觉得 AI 最擅长处理什么？”

老王想了想：“文本？”

“对，AI 就是文本进、文本出。它没有眼睛，看不了图形界面。”

CLI 和 GUI 的区别就在这里。GUI 是给眼睛看的，打开 app，看到按钮菜单，鼠标点来点去。CLI 是纯文本的，打开一个黑色窗口，敲一行文字，按回车，事情做完了。

打个比方，GUI 是去餐厅看菜单、指给服务员“我要这个”。CLI 是直接对厨房喊“油泼面，少油，多辣”。结果一样，但 CLI 更精确，更容易被自动化。

“所以 CLI 和 AI 特别适配？”老王追问。

“对，AI 原本就生活在命令行的世界里。”

AI 想帮你压缩视频，不需要打开 Premiere 找导出按钮，跑一行 ffmpeg -i input.mp4 -crf 28 output.mp4 就完事了。人类没有重新爱上命令行，是 AI 原本就生活在命令行里。

老王点点头：“那为什么以前 CLI 没这么火，偏偏是现在？”

02、AI 的能力边界在哪？

我说：“王哥，这就要说到 AI 的能力边界了。”

很多人把 AI 想象成全知全能的大脑。但更准确的比喻是：一个非常聪明的新员工，什么都能学，学得快，但需要两样东西——工具和说明书。

装了 ffmpeg，AI 能处理视频。装了飞书 CLI，AI 能帮你查日程、发消息。装了网易云音乐 CLI，AI 能管你爱听的歌。

没装？“不好意思，这个我做不了。”

AI 的实际能力 = 它能调用的工具 + 它拿到的上下文。

所以如果你感觉 AI 很智障，大概率是他的上下文不够大，给他的工具不够多。

就比如说，如果没有飞书 CLI，让大模型帮我们根据多维表格生成词云图，几乎没办法办到。

“工具好理解，上下文是什么？”老王追问。

“上下文就是说明书。”

就比如说，飞书 CLI 是 2026 年 3 月底刚发布的，AI 的训练数据里完全没有，如果我们不给说明书，AI 根本不知道它存在。

所以新一代 CLI 工具都自带很多种 Skill，我昨天在装飞书 CLI 的时候就安装了 19 个 Skill，Skill 本质就是 Markdown 写的说明书，告诉 AI 这个工具能做什么、怎么用。

老王若有所思：“工具越新，AI 越依赖说明书？”

“对，训练数据永远追不上工具发布速度，说明书会越来越重要。”

03、传统 CLI 和现在的 CLI 有什么区别？

老王话锋一转：“CLI 不是几十年前就有吗？怎么感觉你说的像是新东西？”

“王哥，过去的 CLI 和现在的 CLI，虽然都叫 CLI，已经是两种东西了。”

传统 CLI，比如 curl，是给程序员用的。输出是给人眼看的彩色文字，遇到需要选择的时候会弹交互式菜单。对人来说很自然，但 AI 遇到这种弹窗直接卡住。

curl -si https://paicoding.com

新一代 CLI 从设计之初就假设调用者是 AI Agent：所有操作通过参数一次性传入，不弹菜单；输出 JSON 格式，AI 直接解析；自带 Skills 说明书；支持 --dry-run 预览，让 AI 执行前先看看会发生什么；AI 还能问工具“你有哪些命令？需要什么参数？”不用读完整文档。

“举个例子？”老王说。

“飞书 CLI。装完以后 200 多条命令，覆盖日历、消息、文档、任务、邮箱等 11 个领域。比如查看今日日程：”

lark-cli calendar +agenda

“查询多维表格数据：”

lark-cli base +query --table appXXX --fields "姓名,学校,专业"

“创建云文档并导入 Markdown：”

lark-cli docs +create --title "面试指南" --file ./interview.md

“这些命令，AI 可以直接调用，不需要打开飞书 app。”

老王点点头：“这确实和传统 CLI 不一样。输出的格式呢？”

“默认是 JSON，AI 可以直接解析。比如查日程的输出：”

{
  "events": [
    {
      "id": "evt_xxx",
      "summary": "谁是逗比大会",
      "start": "2026-03-30T14:00:00",
      "end": "2026-03-30T15:00:00",
      "attendees": ["王二", "陈清扬"]
    }
  ]
}

“AI 拿到这个 JSON，就知道你下午两点有会，参会人是谁，可以直接帮你安排后续工作。”

04、CLI 和 MCP、Skills、Plugin 的区别？

老王追问：“我听说 AI 圈一直在争论 MCP、Skills、Plugin 哪个会成为主流，你怎么看？”

我说：“仔细看新一代 CLI 在做什么，会发现 CLI 把这三样全打包了。”

先解释三个概念。MCP是 AI 和外部服务之间的标准通信协议，理解成 AI 世界的 USB 接口。Skills是告诉 AI“这个工具怎么用”的说明书。Plugin是把工具、协议、说明书打包在一起的可安装扩展，类似手机上的 App。

飞书 CLI 就是典型：CLI 命令提供执行能力，内置 MCP 服务提供标准通信协议，自带 Skills 文件充当使用说明书。

“一个 CLI 工具就是一个事实上的 Plugin。”我说。

“但它比 Plugin 多了几个好处。”老王接话。

“王哥你也注意到这点了？”

Claude Code 的 Plugin 只能在 Claude Code 里用。

飞书 CLI 装了以后，Claude Code、Codex、Qoder 都能用。

并且 CLI 不关心调用它的是哪个模型，它是模型无关的执行层。

CLI 还有一个很大的优势，就是管道。举个场景：我有一个智能客服系统，每天要生成运营日报。传统做法是：运营人员导出数据、整理 Excel、写分析文字、发邮件。

用 CLI 组合呢？

# 第一步：从客服系统拉取对话数据
cs-cli conversations export \
  --date yesterday \
  --format ndjson

# 第二步：管道传给分析工具，提取关键指标
| jq -c '{total: .total, resolved: .resolved, avg_response_time: .avg_time}'

# 第三步：管道传给AI生成报告
| ai-cli generate \
  --prompt "根据这些数据生成运营日报，包括问题分布、处理效率、改进建议" \
  --output markdown

# 第四步：管道传给飞书，自动发到团队群
| lark-cli message send \
  --chat-id oc_xxx \
  --msg-type post

一条管道，四个工具，从数据拉取到报告发送，全自动完成。人只用在早上看一眼群消息就行。

老王感慨：“大家争 MCP、Skills、Plugin 哪个会赢，答案可能是 CLI 把它们全打包了，而且跨平台。”

05、你觉得以后产品都会 CLI 吗？

老王突然问：“你有没有这种感觉，大部分时间我们不是在写代码，而是在确认 AI 的交付结果。”

“一样，王哥。”

“我觉得，如果以后所有的工具都提供了 CLI 的接入方式，直接指示和赋能 AI Agent 去干活，我们就不再被结果确认占用时间了。”

“AI 时代，服务的接口不应该是图形界面，而应该是命令行。”

如果产品只有网页版，用户想让 AI 帮忙操作，就得让 AI 打开浏览器、点击按钮、填写表单。这一套下来，复杂度极高。

但如果产品有 CLI，AI 只需要跑一行命令就完事了。效率差距是数量级的。

“飞书就做到了这点。这样开发者不需要自己去对接飞书开放平台的 API，装个 CLI 就能用。”

06、做一个 CLI 需要注意什么？

老王追问：“那如果我是开发者，我也想给自己的产品做一个 CLI，应该注意什么？”

我说：“王哥，这个问题我研究过，有五个关键点。”

第一点：不要弹交互式菜单。 传统 CLI 喜欢在遇到选择时弹出菜单，让用户上下键选择。

比如 ? Which environment? 这种。对人来说很自然，但 AI 遇到这种弹窗直接卡死。

正确的做法是：所有选项通过参数一次性传入。如果必须交互，提供 --no-interactive 参数让 AI 跳过。

第二点：输出 JSON 格式。 AI 最擅长处理结构化数据。正确的做法是：默认输出 JSON，或者提供 --output json 参数。这样 AI 可以直接解析，不需要额外处理。

[{"text": {"title": "使用仪表盘的词云图表", "description":
  "一、功能简介\n在多维表格仪表盘中，你可以使用词云图表将文本数据进行视觉化的展示。词云图可以根据
  指定的词频或基于智能分析结果，将高频词汇通过颜色及字体大小突出展示。适用于热点用词分析、用户意
  见统计等需要从大规模文本中提炼关键信息的场景。\n二、操作流程\n添加词云图\n进入目标多维表格，点
  击左侧导航栏中的仪", "url": "https://www.feishu.cn/hc/zh-CN/articles/709166668964", "content":
  "使用仪表盘的词云图表", "meta...

第三点：提供--dry-run 预览。 AI 执行命令前，最好先看看会发生什么。特别是删除、修改这种危险操作。正确的做法是：提供 --dry-run 参数，让 AI 在真正执行前预览结果。这样可以大大降低误操作的风险。

第四点：控制输出大小。 用 field masks 控制返回字段，或者提供 --fields 参数让 AI 指定只返回哪些字段。比如查邮件只要主题和发件人，不要正文。

第五点：写好 Skills 说明书。 Skills 文件要精准，不要太大。建议控制在 1.6KB，这是一个很好的参考。只写 AI 需要知道的，不要写废话。

老王追问：“Skills 文件具体怎么写？能给我看看吗？”

我说：“飞书 CLI 开源了，我们可以直接看它的 Skills 目录。”

飞书 CLI 的 Skills 目录下有 19 个文件，每个对应一个业务领域。比如 lark-base.md 是多维表格操作的说明书，lark-calendar.md 是日历操作的说明书。每个 Skills 文件都包含：工具概述、可用命令、参数说明、使用示例。格式清晰，AI 读完就知道怎么用。

“而且飞书 CLI 还提供了 skill-template 目录。”我说，“如果你想给自己的产品写 Skills，可以直接复制这个模板，改成自己的内容就行。”

老王听完点点头：“这五点都很实用。”

07、怎么管理 CLI？

老王突然问了一个有意思的问题：“如果用户装了很多 CLI 工具，怎么管理？”

“王哥，这个问题我也思考过。有一个很有意思的思路，让 AI 管理自己的工具。”

传统软件思路是：写代码嗅探用户系统装了什么、写 UI 让用户在界面上管理工具、写逻辑检测更新。标准做法，但工作量巨大，而且每个工具的情况都不一样，用代码写死安装逻辑是写不完的。

但 AI 时代有一个更好的思路：既然产品里已经有 AI 了，为什么要绕过它？

安装工具，直接拉起对话让 AI 来。AI 读 --help，判断操作系统，处理权限错误，引导认证配置。安装报错了它能读错误信息自己判断，要不要 sudo？先装个依赖？换个源？

注册工具也一样，给 AI 一个提示词模板，读完 --help 自动生成结构化描述，工具能做什么、怎么用、典型场景。

“这个思路有意思。”老王眼睛一亮，“等于说 AI 既是工具的使用者，也是工具的管理者。”

“对，这就是 AI 时代的产品设计思路，别用软件帮用户管理 AI 的工具，让 AI 管理自己的工具。”

老王追问：“那更新呢？工具更新了怎么处理？”

“更新更简单。AI 定期检查工具版本，发现新版本就提示用户是否更新。更新过程中遇到问题，AI 自己读错误日志判断怎么解决。整个过程用户只需要点一下确认，剩下的 AI 全包了。”

08、CLI 的未来

老王问：“你觉得 CLI 未来会怎么发展？”

我说：“有几个趋势比较确定。”

趋势一：CLI 会成为产品的标准配置。 以后每个 SaaS 产品，除了网页版、app 版，还会有 CLI 版。不是可选的附加功能，而是标配。

因为 CLI 是 AI 调用你产品的最佳接口，没有 CLI 就等于放弃了 AI 这个用户群体。飞书开了个头，接下来会有更多产品跟进。

趋势二：会出现 AI 工具的 App Store。 未来一定会出现专门索引 AI 工具的平台，可能是由 npm、GitHub 来做，也可能是由新的创业公司来做。

谁能做成这个，谁就是 AI 时代的 npm。这个机会很大，现在还是空白。

老王听完感慨：“这两个趋势，每一个都是机会。那你觉得普通开发者能做什么？”

“两件事。第一，学会用好现有的 CLI 工具，提升自己的生产力。第二，如果有机会，给自己的产品做一个 CLI，这是进入 AI 生态最直接的方式。”

09、所以，为什么大家都在做 CLI？

老王问出最后一个问题：“总结一下，为什么一夜之间大家都在做 CLI？”

我说：“王哥，大家意识到 CLI 可能是当下效率最高的 AI 能力分发方式。”

一个 CLI 工具同时包含执行能力、通信协议和使用说明，就是一个完整的 AI 插件。跨平台，免审核，人和 AI 都能用。每多装一个好用的 CLI 工具，你的 AI 就多一项技能。每少一分多余的上下文噪音，你的 AI 就聪明一点。

“具体说说？”老王追问。

“王哥，你看飞书 CLI 出来之后，我做了什么。”

我用飞书 CLI 让 AI 帮我分析了 600 多条简历数据，生成了词云图，还把 18 篇面渣逆袭文章全部上传到了飞书云文档。整个过程我没写一行代码，没打开飞书网页，全是 AI 通过 CLI 自动完成的。

https://my.feishu.cn/wiki/CScqwBVyliWpRYkJEAWc9ouxnZf?from=from_copylink

如果没有 CLI 呢？我得先去飞书开放平台创建应用、配置权限、写代码调 API、处理分页、处理图片上传、处理格式转换。一套下来，一天就没了。

有了 CLI 呢？装一次，扫个码，AI 就能直接干活。效率差距是数量级的。

“而且 CLI 有个好处，一次安装，处处可用。”我说，“我在 Qoder 里装了飞书 CLI，换到 Codex、Claude Code 里都能用，不需要重复配置。这是 Plugin 做不到的。”

老王点点头：“这确实解决了跨平台的问题。”

我们正处在一个混乱的新旧交替时代。旧的格式、旧的数据壁垒、旧的包管理器，和新的 AI 原生工具链交织在一起。

老王沉默了两秒，然后说：“你什么时候能来上班？”

10、CLI 如何写到简历上？

项目名称：AI Agent CLI 工具集成项目

项目简介：基于飞书 CLI 等 AI 原生命令行工具，实现业务数据的自动化分析和文档管理，提升数据处理效率 10 倍以上。

核心职责：

集成飞书 CLI 等 AI 原生工具，实现业务数据自动采集与分析，覆盖 11 大领域 200+命令，日均处理数据 500+条
利用 AI Agent + CLI 管道组合，完成批量文档转换与上传，18 篇万字文档一键同步飞书云空间
编写自定义 Skills 文件，指导 AI 正确调用工具，准确率达 95%以上，减少 AI 幻觉导致的误操作
设计并实现 CLI 工具管理方案，支持跨 Agent 平台复用，工具配置时间从 30 分钟缩短至 2 分钟

Karpathy 说得对：每一个产品都应该有一个 CLI 工具。不要让开发者去访问、查看或点击。直接指示和赋能他们的 AI。

【CLI 不是复古，是 AI 时代被重新发明的基础设施。】

CLI 这波浪潮，才刚刚开始，机会巨大。

我们下期见！

## 01、为什么需要 Harness Engineering

先说一个扎心的现象。

很多团队上了 Agent 之后，发现一个尴尬的事实：模型能力明明够用，但任务就是跑不好。

你让它写个简单功能，它给你整出花里胡哨的设计模式；你让它修个 bug，它改完一处忘了另外三处关联的地方；你让它做一个长任务，它跑着跑着就不知道自己在干嘛了。

问题出在哪？

不是模型不够聪明，是模型太“自由”了。没有人告诉它边界在哪、什么时候该停、出错该怎么恢复。就像你招了一个能力很强的员工，但没有给他配工作流程、没有检查机制、没有反馈回路，最后效果一定是一地鸡毛。

Prompt Engineering 解决的是“怎么让模型听懂你的话”，Harness Engineering 解决的是“怎么让模型把事做完”。

两者的核心区别在于：

Prompt Engineering 关注的是输入，你怎么问、模型怎么答。它的一切优化都围绕着“让模型一次答对”。

Harness Engineering 关注的是整个执行环境。模型答错了怎么办？上下文乱了怎么恢复？子任务怎么调度？这些都需要一套基础设施来兜底。

打个比方：Prompt Engineering 是在教员工怎么听懂你的指令，Harness Engineering 是在给员工配一套完整的工作台——工具有、流程有、检查清单有、出错报警也有。

这就是为什么硅谷开始流行一句话：2025 年是 Agents 的元年，2026 年是 Agent Harness 的元年。

02、Harness Engineering 是什么

Harness Engineering 的核心公式非常简单：

Agent = Model + Harness

Model 是大模型本身，负责理解和生成。Harness 是包裹在模型外围的运行时控制系统，负责调度、约束、恢复和审计。

一个完整的 Harness 包含六大核心组件：

第一个，标准化工具集成层

Agent 需要调用各种外部工具——写文件、调接口、操作数据库。

但每个工具的调用方式不一样，错误处理也不一样。Harness 的做法是在所有工具调用前加一层“钩子”，统一做参数校验、权限检查、异常兜底。

这样当某个工具挂了，Harness 可以自动降级或者重试，而不是让整个任务崩溃。

第二个，上下文工程系统

传统的做法是把所有对话历史塞进 context window，但这种方式在长任务里会越来越乱。

Harness 的做法是用“结构化状态”替代聊天历史——把任务拆成清晰的阶段，每个阶段有明确的输入输出，模型只需要看当前状态，不用管之前说了多少废话。

第三个，状态持久化与任务调度引擎

Agent 跑着跑着断了怎么办？

Harness 提供断点续传和 Checkpoint 机制。任务执行到哪一步、当前状态是什么、下一步要做什么，全部持久化存储。

随时可以恢复，也支持并行调度多个子任务。

当我给 Claude Code 一个复杂任务时，它不会直接开始写代码。它会先：

第一步，探索代码库。 搞清楚项目结构、依赖关系、现有实现方式。这一步相当于工程师接需求前的“读代码”阶段。

第二步，制定执行计划。 把大任务拆成小步骤，标明每一步要做什么、改哪些文件、可能的依赖关系。这一步相当于写技术方案。

第三步，逐个执行并检查。 每完成一步都会验证结果，发现问题就调整。这一步相当于代码评审和自测。

第四步，全局检查。 所有步骤完成后，扫一遍有没有遗漏的地方、潜在的边界问题。这一步相当于上线前的回归测试。

这四步不是写在提示词里的，而是 Claude Code 的 Harness 内置的执行框架。模型只需要遵循这个框架，就不会出现“改了一处忘了关联的三处”这种低级错误。

还有一个细节让我印象深刻。

在执行过程中，如果遇到需要用户确认的操作（比如删除文件、修改敏感配置），Claude Code 会暂停下来让你确认。

这不是模型的“自觉”，而是 Harness 里的“钩子”拦截了高风险操作，强制要求人工审批。

这就是 Harness 的价值：把“信任模型”变成“信任框架”。模型可以犯错，但框架能兜住。

04、用 PaiAgent 实测 Harness 设计

我用 PaiAgent 项目做了一个小实验，看看 Harness 在实际开发中到底能起多大作用。

https://github.com/itwanger/PaiAgent

PaiAgent 是一个 AI 工作流编排平台，核心功能是让开发者通过拖拽节点的方式来编排 AI 任务。

之前我遇到一个典型问题：工作流执行到一半，如果某个节点出错了，整个任务就挂了，没有任何恢复机制。

我尝试用 Harness 的思路来解决这个问题。

https://github.com/bytedance/deer-flow

它的核心特点有三个：

第一个，子代理与沙箱隔离。

每个子 Agent 都在独立的沙箱环境里运行，有自己的文件系统、网络隔离、资源限制。

一个子 Agent 搞坏了不影响其他的，也不会污染主环境。

第二个，结构化的任务状态。

不再是把所有对话塞进 context，而是把任务状态抽象成清晰的数据结构——当前阶段、已完成步骤、待办事项、依赖关系。

模型只需要读结构化数据，不用管冗长的对话历史。

第三个，可插拔的工具链。

工具调用被封装成标准接口，支持热插拔。新增一个工具不需要改框架代码，只需要按规范实现接口就行。

这套方案的价值在于，它把“写 Agent”这件事从“调模型”升级到了“配置 Harness”。你不需要关心模型怎么调度、怎么恢复、怎么隔离，Harness 都帮你搞定了。

从 GitHub 的数据来看，DeerFlow 2.0 上线不到一个月就斩获了 54.7K Star，说明这个方向确实是刚需。

05、从写代码到设计环境

Harness Engineering 带来的一个重要变化是工程师角色的转变。

过去我们写代码，是直接告诉计算机每一步该怎么做。现在做 Agent，是设计一套环境，让模型在这个环境里自己完成任务。

具体来说，工程师的工作重心从：

写具体的业务逻辑代码
处理各种边界情况和异常
手动调试和修复问题

变成了：

设计 Agent 的执行框架和约束条件
配置工具调用接口和权限边界
定义状态流转和恢复机制
搭建可观测和审计系统

OpenAI 内部已经有团队用 Agent 写了百万行代码，人类工程师的角色从“写代码的人”变成了“设计系统的人”。

Anthropic 的做法也很有意思。他们通过“角色分离”来解决自我评估的偏差问题——让一个 Agent 负责写代码，另一个 Agent 负责评审，两者独立运行，避免“自己给自己打分”的盲区。

这些都是 Harness Engineering 的实践思路：不是让一个模型搞定所有事，而是设计一套系统，让多个角色协作，互相校验，最终产出可靠的结果。

06、怎么落地 Harness Engineering

如果你想在团队里落地 Harness Engineering，可以从三个层面入手。

工具层：给你的 Agent 加钩子。

在工具调用前后加拦截器，做参数校验、权限检查、日志记录。这是最轻量的 Harness 实现，改造成本低，但能解决大部分“一着不慎满盘皆输”的问题。

框架层：引入现成的 Harness 框架。

LangChain 的 DeepAgents、Claude Code 的执行框架、DeerFlow 的子代理系统，都是可以复用的。

不需要从头造轮子，站在巨人肩膀上更快。

平台层：搭建 Agent 运行时平台。

如果你的团队有大量 Agent 需求，可以考虑搭建统一的 Agent 运行时平台——集中管理 Agent 的配置、调度、监控、审计。这是最重的方式，但收益也最大。

从性价比来看，建议从工具层开始，先解决最痛的点，再逐步往框架层、平台层演进。

一个真实的落地案例。

我团队有个需求：每天自动从多个数据源抓取数据，生成一份运营日报。之前用简单的脚本实现，经常因为某个数据源超时导致整个任务失败，而且失败了我们也不知道，第二天才发现昨天的日报没生成。

用 Harness 的思路改造后：

工具层改造：给每个数据源抓取加了一个超时控制和异常捕获。如果某个数据源挂了，记录错误但不影响其他数据源，最后生成的日报会标注哪些数据缺失。

框架层改造：引入了一个轻量级的任务调度框架，支持失败重试和告警通知。如果日报生成失败，自动发钉钉消息通知值班人员。

平台层规划：后续打算把所有类似的定时任务都接入统一的调度平台，集中管理、统一监控。

这就是 Harness Engineering 的落地价值：不是追求一步到位，而是根据业务痛点，分阶段、有节奏地建设。