AI on 冯威的博客

聊聊最近的 Vibe Coding 经历

Mon, 27 Jul 2026 08:50:00 +0800

最近花了很大精力在 Vibe Coding 上，当然也做出了不少东西，时间被 token 占据着，公众号也断更了一段时间。

最近一个很大的感触是使用 AI ，思维方式得转过来。第一步是"相信它能"，不信就不会去试，不试就永远停留在浅层用法；第二步是探索，在探索中碰到"不能"；碰到不能时多问一句：是模型真不行，还是我方法不对？换个提示、拆下任务、补点上下文，很多"不能"其实是"还不会用"。如此反复。

还记得春节前我有一个功能的想法，在网页 Chat 模式下沟通几轮得到一个原型界面，还是会安排开发人员去进行最终的实现。

春节期间，我决定得要自己动手去实践，于是我找了个中转站充了 50 块，客户端使用 Claude Code，接中转站的模型，就开始了 Vibe Coding 之旅。

开发了一个研发内部使用的平台，将需求、任务、待办、缺陷管理起来，后面还陆续加入了文档中心、分享中心等功能。

研发管理类的工具有很多，为什么还要自己去重复造轮子呢？

原因很简单，要想使用 AI 给团队内部提效、要想利用 AI 给客户带来价值，就必须要对 AI 有深入的了解才行。去真正做出一些东西，才可以更好的了解。

我自认为对开发非常了解，对研发内部的管理业务也很清楚，理论上来说，应该很容易借助 AI 的能力把这个系统给开发完成，但其中还是碰到了很多的问题。

中转站的模型能力时好时坏，有时候还会碰到直接挂掉
UI 一致性的问题：同样的 Tab 切换，在不同的功能模块都自成一个体系
有时候只是想问一下情况或者让分析一些内容，但话音刚落，AI 马上就开始改代码，就像是一个初级程序员一样，特别喜欢直接上手改代码
添加新功能，之前的功能给改坏了

因为要做的是一个需要持续迭代的软件系统，不是一个 Demo，所以并不是说一句话让 AI 生成一个开盲盒式的系统就完事了，需要提前做很多很多的准备。

比如，以下内容需要沉淀到文档里面：

前后端都需要使用什么技术栈；
数据库的设计、接口的定义；
每个功能模块的描述，业务目的是什么，以及该怎么去实现。
每次 AI 修改完代码，修改了什么内容？

开始的时候会先做静态页的 UI 原型，包括布局和一些交互，慢慢调到比较满意之后，再让 AI 把它转换成前端的代码。等整个系统的结构差不多构建起来之后，这个就弃用了，直接让 AI 基于现有的 UI 风格进行新功能的开发。

一种有效的方法是，当一个事情反复沟通才能达到效果，我会让 AI 对多轮对话进行总结，有些规则可以沉淀到 CLAUDE.md 、AGENTS.md 中，有些是沟通话术的问题，我后续可以进行调整。

中转站前后换了好几个，最后的结论还是买正版吧。中转站质量掺水不说，而且还极其不稳定。现在模型能力越来越强，不管是用国内的还是国外的，比如 K3、GLM 5.2、DeepSeek V4 或者 GPT 5.6 来做开发，都没有任何问题。

从 3 月 11 号开始，我的主力工具就是 codex 了。从开始的 Plus 到后来使用 Pro，目前 Pro 的额度也渐渐变得不够用了，好在 Tibo 经常会进行重置。

到现在，仅在 Codex 上的 token 消耗量已经接近 200 亿了。下面就说说这 200 亿的 token 都做了些什么。

1、AI 员工平台

起初是想将内部的一些问数场景，知识库场景，利用 AI 来提升一些效率。后来跟 ChatGPT 聊着聊着，就萌生了直接做一个平台的想法。

GPT 告诉我，AI 员工也是一个员工，企业需要给他提供相应的办公环境、知识技能培训等等。我觉得这个思路不错，所以就按照员工和企业这两个维度来构建这个平台。

从 Vibe Coding 到 Harness Engineering

Sat, 16 May 2026 16:05:00 +0800

春节之后一直在深度 Vibe Coding 做一些事情。将最近收集的资料整理后，在 Codex 中使用 baoyu-slide-deck 这个 skill 生成了一组 ppt 图片。

Vibe Coding 现在应该都或多或少尝试过，但都停留在爱简单沟通几轮，做出一个 Demo ，至于效果怎么样，在代码写完之前是不知道的，就像是开盲盒。

所以很多人就觉得 Vide Coding 只能做些示例，还不能上生产。

Vibe 也经历了一些不同的阶段，从提示词、到上下文，再到现在的 Harness Engineering 。

简单来说，我们不只是给模型上下文，而是要为 Agent 构建一整套可执行、可验证、可恢复、可追溯的工程系统。

这也是我理解的 Vibe Coding。

它不应该只是“凭感觉让 AI 写代码”。在生产环境里，它必须是工程化的：人负责表达目标、拆解任务、定义边界和验收标准，Agent 负责搜索代码、生成实现、运行测试和提交变更。

真正的难点，不是让 AI 写出代码，而是让它在复杂代码库里写对代码。

新项目相对容易一些，可以从第一天就按 Agent-Native 的方式建设：目录清晰、规则稳定、测试可执行、文档结构化。

历史项目会更难。几十万行代码里有大量隐性知识：哪些字段有单位约束，哪些链路不能乱改，哪些历史实现只是当时留下的反模式。对 Agent 来说，没被写进代码库、文档、规则和测试里的知识，就等于不存在。

所以 Harness 的核心价值，是把团队经验外部化。Rules 告诉 Agent 标准是什么，Skills 告诉 Agent 怎么做，Wiki 告诉 Agent 系统是什么样，Changes 记录 Agent 做了什么。

再配合需求分析、编码实现、评审、单测、CI、部署验证等，AI 产出才可能从“看起来能跑”，变成“质量可控”。

模型能力决定上限，工程能力决定下限。模型越强，越需要更好的上下文、更严格的约束和更完整的验证闭环。

对研发团队来说，核心竞争力正在迁移。未来重要的不只是会写代码，而是会设计一个让 Agent 稳定工作的系统。

谁能把需求讲清楚、把边界定清楚、把规则写清楚、把验证做清楚，谁就更可能真正把 AI 变成生产力。

AI 时代其实对人的要求更高了

Mon, 02 Feb 2026 10:00:00 +0800

最近项目里发生了一件特别有意思的事，非常值得复盘。

项目经理给一位开发同学布置了一个功能模块，按理说难度不大。考虑到现在 AI 编程工具这么强，项目经理估计很快就能搞定。结果呢？这位同学整整搞了一天还没弄完。

项目经理很纳闷，问他：“你没用 AI 协助吗？”

开发同学一脸苦笑：“用了啊。就是因为用了 AI，我才搞到现在。”

原来，他把需求扔给 AI 后，AI 产出了代码和运行结果，这位开发同学又花了大量时间逐项核对。

最后算下来，效率反倒不如纯手写。

这位同事的问题，在于他依然以“写代码”的思维使用 AI，而不是以“验收结果”的思维。

当我们自己写代码时，脑子里是有完整逻辑的，写出来的每一行都心里有数。但当 AI 生成代码时，对我们来说是一个“黑盒”。

我们需要从执行者转变为架构师视角。

在上面这个场景里，我们如果转变思路，把自己当成一个架构师，把 AI 当成负责编码的程序员。会发生什么？

试想一下，如果你给一位开发派活，你会只说一句“帮我做个登录功能”吗？肯定不会。因为你知道一句话需求会导致最后做出来的东西可能完全偏离了方向。

那要怎么做呢？

我们会写详细的规格说明书和接口文档，明确交付标准。然后将这些告诉开发，要按照这些要求来写代码。

对 AI 也是一样。

结合这个案例，我认为要提高 AI 协作效率，必须做好以下几点：

1、边界

告诉 AI 目标是什么、哪些要做、哪些不能做。只有当 AI 清楚知道“要做什么”并且“什么不能做”时，才能正确执行任务。

2、任务拆解

不要把一个大需求直接丢给 AI。正确的做法是拆解。把大任务拆成一个个独立的、可验证的小的任务。

任务越小，AI 犯错概率越低，检查的成本也越低。

3、反馈

当 AI 给出的结果有问题时，我们要能快速识别，并及时提供反馈。

如何才能快速识别？

这就需要我们掌握架构知识和底层原理，所以说 AI 帮我们提升效率的同时，我们自己的能力也需要提升才能更高效地配合。

好的反馈能让 AI 一次性修正错误，避免陷入无效的反复沟通。这不仅省钱（省 Token），还能让 AI 尽可能少地产生幻觉。

4、上下文

AI 和人一样，需要上下文。

一个新人进入团队，需要熟悉工作环境、使用的工具、项目的情况、文档、代码库等，这些就是上下文；上下文越充分，就越容易上手。

5、目标

我们做项目，客户的真实诉求是什么？挖得越深，就会越顺利，可以在后期避免很多不必要的返工。

指挥 AI 干活，也需要让 AI 知道我们的目标和意图是什么，只有这样，产出才不会有偏差，有时甚至有惊喜。

6、验收标准

把任务指派给 AI，必须让 AI 知道什么叫“做完了”。

不要小看这个“做完了”，很多时候，项目经理和开发的理解都不一样，开发认为代码写完就算是做完了，项目经理要对最终的业务负责，考虑的更全面。

首先我们要明确这个标准，再告诉 AI。否则，如果我们自己都不清楚验收标准，AI 就不可能产出符合要求的结果。

Agent Skills 全景指南：从概念机制到实战开发

Fri, 23 Jan 2026 09:01:00 +0800

最近，Agent Skills 彻底火了。

很多人第一次听到 Skills，会觉得“这不就是一堆 Markdown 吗？”我一开始也这么想。但当你把它放进 Agent 的运行方式里，再对比 Prompt、MCP、Function Calling 这些概念，你会发现：Skills 解决的不是“模型会不会”，而是“怎么让模型稳定、可复用、可分发地把事做完”。

在这篇文章里，我将从概念到实战，带你彻底搞懂 Skills。

一、什么是 Skills？它从何而来？

简单来说，Skills 就是供大模型使用的技能包。

Skills 里面包含做事的方法（流程、规范、检查点），以及可选的资源（模板、脚本、参考资料等）。
目标不是让模型“临场表现更好”，而是让同一类任务在不同时间、不同输入、不同人使用时，都能得到稳定的结果。

例如：团队新来了一个开发工程师。为了让他按团队要求开展工作，通常会告知：

这件事的目标和流程是什么（SOP）
要用到什么工具（Scripts/MCP）
有什么参考模板和素材（References/Assets）

这就是 Skills。它让 Agent 具备了“专业知识”和“稳定做事的方法”。

Skills 最早由 Anthropic 在 2025 年 10 月中旬随 Claude Code 推出。两个月后（12 月 18 日），Agent Skills 被作为开放标准发布。

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills?utm_source=chatgpt.com

二、Skills、MCP、Agent、Function Calling 的关系

之前写过 MCP 和 Function Calling 相关的文章：

《[[MCP 和 Function Calling：概念]]》

《[[MCP 和 Function Calling：示例]]》

这些和新的 Skills，关系是什么呢？

Function Calling：这是最底层的能力，相当于人的“手”。它让 AI 知道自己能“拿杯子”、“按开关”，是连接外部世界的基础接口。
MCP：这是一种标准协议，定义通用通信架构和数据格式（类似于 USB 标准）。Function Calling 可视为 MCP 生态下的一种具体功能实现形式。
Skills：这是业务逻辑和流程，相当于“脑子里的知识”。它教 AI 如何使用 MCP 里的工具去完成一个复杂的任务（比如写一篇符合你风格的文章）。它解决的是“流程”问题。
Agent：Agent 是位于最上层的“大脑”或“协调者”。

可以这么理解，不一定准确：Agent 是工人、Function Calling 是工人具备使用工具的能力，比如会用锤子等、 MCP 是一个多功能腰带，有各种标准的卡口用来放不同类型的工具、Skills 可以是这些工具的使用说明书，也可以是怎么用工具造房子的施工图纸。

三、核心机制

Skills 的核心机制，我认为就两件事：

让 Agent 能“找到该用哪个技能”
让 Agent 能“只在需要时加载需要的部分”

Agent 启动时不会把所有技能全文塞进上下文窗口，而是先扫描技能包，读取每个技能的少量元信息（名称和描述，描述尤为重要）。

当用户提出需求后，Agent 会用这些元信息做匹配，判断要不要触发某个技能。这也是为什么 Skills 的 description 写得好不好，直接决定“命中率”。

AI 时代，低代码该如何演进？

Tue, 04 Nov 2025 14:49:45 +0800

在数字化转型的浪潮中，低代码平台与人工智能（AI）的结合正成为企业软件发展的关键趋势。

低代码平台以其快速开发、交付等特性，正在改变企业应用的开发方式，而 AI 把企业从 “流程数字化” 推进到 “决策智能化” 。这两者一定可以碰撞出不少的火花。

本文探讨低代码与 AI 融合的方式。

低代码和 AI 有两种方式可以结合

方式一：在低代码平台中使用 AI，把 AI 能力沉淀到平台内部，提升用户体验和效率。
方式二：在 AI 中使用低代码，将平台的核心能力封装成细颗粒度工具，成为大模型与智能体的“手脚”。

这两种方式并非二选一，而是相互增强，根据客户的业务场景进行取舍和选择。

方式一：低代码中使用 AI

低代码的优势是可以快速交付项目，结合 AI ，可以让构建出来的业务系统具备 AI 能力，在低代码平台中 AI 能力了可以通过组件或插件的形式存在。

下面列举几种常见的场景。

企业级智能问答

RAG 现在在企业中使用已经非常成熟了，RAG 中有一个关键点是将内容进行向量化，供用户提问时使用。

低代码平台中天然就有很多的数据：

低代码平台可以搭建各种业务功能，随着用户的使用，业务数据就会累加，可以在平台中根据配置选择性将业务数据纳入到知识问答的范围。
低代码平台中的文件列表，在用户上传文件时，可以对文档内容进行读取和向量化。
在使用低代码平台构建应用时，数据库表的创建是根据平台中的数据模型进行转换的，数据模型就是一份数据库表的元数据。

至于前端的问答对话框的呈现就比较灵活了，可以是单独一个页面、可以放到首页，也可以放到某个功能模块中，针对具体的业务进行提问。

审批流 AI 节点

企业将线下的审批搬到线上，为的就是能提高效率。某些审批环节，如果能使用 AI 加持，就能更进一步。

比如：员工报销流程，财务会对上传的发票和报销金额进行审核，当一个报销单的发票比较多时，人工核对会非常麻烦。

结合 AI ，可以在低代码平台的流程引擎中提供一个 AI 辅助审批节点，发起人提交后，将票据传给 AI ，AI 进行金额的识别和汇总，并根据规则配置和报销金额进行比对，发现问题直接驳回给发起人。

报表多轮对话

我们现在给企业客户开发软件的过程中，根据客户的业务需求，会提供很多的报表，有些是专业的报表工具、有些通过视图关联多表查询出结果展示。

但这些随着需求的确定，功能就固化下来了。客户在使用的过程中只能通过条件进行筛选。

结合 AI ，用户可以在现有报表数据的基础之上进行二次提问，结果以文字、表格、图表的方式提供，让报表变得更加灵活。

文档解析

企业中有很多不同类型的文档和单据，比如：合同、发票等。可以在低代码平台中添加文档识别组件。

利用文档识别组件，可以构建一个专门用来管理票据的功能。
合同管理中在文档识别组件中上传，识别合同基本信息，一键将识别的信息填写到表单中。

除了基本信息，甚至可自动识别文档中的关键节点，如合同中的付款信息与时间等，并同步至低代码构建的事务跟踪系统，显著减少人工查阅与录入的工作量。

方式二：在 AI 中使用低代码平台

AI 只有具备了生产能力，才能真正帮到我们。怎么才能具备生产能力呢？就是使用工具。

我们和大模型进行对话，大模型理解了我们的意图，还能调用工具去进行实现，才是有用的。低代码平台中有各类引擎（表单、规则、视图、流程等），这些引擎的能力可以进行拆解和重组，以 MCP 工具的形式提供给大模型。

场景一

用户指令：创建一个员工信息管理应用，包含姓名、工号、部门和入职日期的表单，以及一个可以搜索和分页的表格。

工具调用：大模型理解意图后，调用低代码平台的 API，自动创建数据模型、生成对应的表单页面和列表页面，并配置好基本的数据绑定。

场景二

用户指令：任务管理中创建任务后，给任务负责人发送一个企业微信通知。

工具调用：大模型理解意图后，分析需要调用的工具集，先调用低代码平台的 API，创建一个用于发企业微信消息的业务流。然后调用 API 将任务创建后的事件和业务流进行绑定。

场景三

用户指令：检查一下我们所有低代码应用的运行健康状况。

工具调用：大模型理解意图后，调用平台的监控API，获取应用错误日志、性能指标（如响应时间）、资源使用情况等，并生成摘要报告。

最后

网上都说，AI 的到来最终会转向无代码，不过从目前来看，让 AI 自己去实现一个复杂系统，还是比较困难，特别是多轮对话后，幻觉比较明显。

低代码平台天生就是构建应用的利器，而且是有规则的，这个规则相比较编程语言，范围更小，更容易被 AI 所理解。

所以，在 AI 无代码变成这条路上，低代码平台如果能转变为底层支撑的工具，将会继续存在。

未来，随着模型能力的持续进化与平台工具的日益精进，人机协同的开发新模式将成为企业数字化转型的核心竞争力。

如何构建多智能体系统？

Wed, 25 Jun 2025 15:51:00 +0800

6 月 13 日，Anthropic 发布了一篇《How we built our multi-agent research system》的实战经验文章，文章分享了 Anthropic 在构建多个 Claude 智能体来更有效地探索复杂主题的系统过程中，遇到的工程挑战和获得的经验教训。

原文地址如下：

https://www.anthropic.com/engineering/built-multi-agent-research-system

全文翻译可以看：https://www.fwhyy.com/2025/06/how-to-build-a-multi-agent-research-system-translation/

下面是我看文章时记录的一些知识点：

1、在过去十万年里，单个人的智力并未发生巨变，但人类社会在信息时代的能力却呈指数级增长，这得益于我们的集体智慧和协调能力。所以说要想突破能力极限，还得靠协作。

2、映射到现在的智能体就是单个智能体会出现 token 使用的极限，多智能体可以使用更多的计算资源来处理现实问题。

3、多智能体的功能架构是协调者和工作者模式，有专门负责分析和指派任务的智能体，也有负责特定工作的智能体。有点像一个项目团队中的项目经理和项目的其他成员。

4、多智能体的一个应用场景是做问答类的应用，和 RAG 不同的是，RAG 依赖静态检索，根据查询的问题找相似块，然后组织成答案。多智能体是多步骤进行检索，动态发现关键信息，并且还会对结果进行分析，进而做进一步分析和处理，使答案有更高的质量。

5、多智能体在运行时，会遵循下面步骤。

系统会先创建一个主智能体，进行任务的思考，然后制定计划，将计划保存起来。
主智能体会创建一个或多个子智能体，进行具体任务的分配。
每个子智能体独自研究并将结果返回给主智能体。
主智能体会判断是否需要进行进一步研究，如果需要会创建额外的子智能体，这个过程是一个循环。
当主智能体发现不用继续研究，会退出循环，将所有结果交给引文智能体进行引文标记的工作。

6、大模型虽然越来越强，但提示词依然很重要，每个智能体都是由提示词进行引导，我们需要使用日志记录的方式来检查智能体的行为，观察什么时候会出错，然后优化提示词。

7、主智能体在进行任务的分配时，需要将需求写的尽可能明确和详尽，这样子智能体才能更好的执行。

8、提示词有个伸缩规则，能够区分简单的事实查询还是复杂问题的研究，让智能体的资源利用率达到最高。现在向深度思考的大模型一些简单的问题，比如：今天星期几？1+1 等于几？大模型还是会自言自语分析一通，很久才会给出答案。这应该就是伸缩规则没有做好。

9、良好的评估对于构建可靠的 AI 应用至关重要，智能体也不例外。即使输入完全相同，智能体也可能采取完全不同的路径来达到目标。所以，我们需要灵活的评估方法，既能判断智能体是否得到了正确的结果，又能判断它们是否遵循了合理的过程。

10、这个评估方法有下面几个标准。

事实准确性（声明是否与来源匹配？）
引文准确性（引用的来源是否与声明匹配？）
完整性（是否覆盖了所有被要求的内容？）
来源质量（是否使用了主要来源而非质量较低的次要来源？）
以及工具效率（是否以合理的次数使用了正确的工具？）

11、当然，多智能体也有缺点，比如消耗 token 会非常快，对于智能体之间需要共享上下文、或者智能体之间要频繁交互的不太适合。A2A 的发展应该有助于多智能体的普及。

读完 Anthropic 的多智能体文章，我也结合我自己的知识有了一些思考。

1、现阶段，由于单智能体 token 的限制，导致会往多智能体发展，否则很多复杂任务无法进行。但如果有一天技术的进步让 token 的限制不存在了，应该又会回归到单智能体。或者说当 token 不存在限制，智能体之间交互没有障碍，就可以根据场景灵活选择了。

2、在大模型能力还没那么强的时候，提示词工程很火，后来模型能力增强，特别是推理型模型出来后，提示词工程被弱化了。这篇文章强调提示词依然非常重要，提示词不只是语言沟通，更是任务分配、格式规范的集中承载体。提示词工程是值得系统去学习的。

3、即使输入完全相同，智能体也可能采取完全不同的路径。也就是说输出是不确定的，尽管可以让大模型进行自评估来提升结果的质量，但对于容错率很低的场景，怎么能保证前 100 次都是对的，第 101 次就不会出现错误呢？

4、都说 AI 的发展会淘汰掉部分程序员，但从这篇文章表达的思想来看，具备架构思维和能力的程序员一定在未来有一席之地。需要关注整体流程、关注错误处理机制（风险）、关注对结果的评估等。

如何构建多智能体研究系统（翻译）

Fri, 20 Jun 2025 15:26:00 +0800

我们的研究功能使用多个Claude智能体来更有效地探索复杂主题。我们分享了构建这个系统时遇到的工程挑战和学到的经验教训。

Claude现在具备研究能力，可以在网络、Google Workspace和任何集成中搜索，以完成复杂任务。

这个多智能体系统从原型到生产的过程教会了我们关于系统架构、工具设计和提示工程的重要经验。多智能体系统由多个智能体（自主使用工具循环的LLM）协同工作组成。我们的研究功能包含一个基于用户查询规划研究过程的智能体，然后使用工具创建并行智能体同时搜索信息。具有多个智能体的系统在智能体协调、评估和可靠性方面带来了新的挑战。

这篇文章分解了对我们有效的原则——我们希望您在构建自己的多智能体系统时能够发现它们的实用价值。

多智能体系统的优势

研究工作涉及开放性问题，很难预先预测所需的步骤。您无法为探索复杂主题硬编码固定路径，因为这个过程本质上是动态的且路径依赖的。当人们进行研究时，他们往往根据发现不断更新方法，跟随调查过程中出现的线索。

这种不可预测性使AI智能体特别适合研究任务。研究需要灵活性，能够在调查展开时转向或探索切向连接。模型必须自主运行多轮，根据中间发现决定追求哪些方向。线性、一次性的管道无法处理这些任务。

搜索的本质是压缩：从庞大语料中提炼见解。子智能体通过在自己的上下文窗口中并行运行，同时探索问题的不同方面，然后为主研究智能体浓缩最重要的标记，从而促进压缩。每个子智能体还提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖性并实现了彻底的独立调查。

一旦智能达到阈值，多智能体系统成为扩展性能的重要方式。例如，尽管个体人类在过去10万年中变得更加智能，但人类社会在信息时代因我们的集体智能和协调能力而呈指数级提高能力。即使是通用智能的智能体在作为个体运行时也面临限制；智能体群体可以完成更多工作。

我们的内部评估显示，多智能体研究系统在涉及同时追求多个独立方向的广度优先查询方面表现尤为出色。我们发现，以Claude Opus 4为主智能体和Claude Sonnet 4子智能体的多智能体系统在我们的内部研究评估中比单一智能体Claude Opus 4的性能高出90.2%。例如，当被要求识别信息技术标普500指数公司的所有董事会成员时，多智能体系统通过将其分解为子智能体的任务找到了正确答案，而单一智能体系统则因缓慢的顺序搜索而未能找到答案。

多智能体系统之所以有效，主要是因为它们帮助使用足够的标记来解决问题。在我们的分析中，三个因素解释了BrowseComp评估（测试浏览智能体定位难以找到信息的能力）中95%的性能差异。我们发现标记使用本身解释了80%的差异，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们的架构，该架构将工作分配给具有独立上下文窗口的智能体，为并行推理增加更多容量。最新的Claude模型在标记使用上充当大型效率乘数，升级到Claude Sonnet 4比在Claude Sonnet 3.7上将标记预算翻倍带来更大的性能提升。多智能体架构有效地扩展了超出单一智能体限制的任务的标记使用。

有一个缺点：实际上，这些架构会快速消耗标记。在我们的数据中，智能体通常使用比聊天交互多约4倍的标记，而多智能体系统使用比聊天多约15倍的标记。为了经济可行，多智能体系统需要任务的价值足够高，以支付增加的性能成本。此外，一些需要所有智能体共享相同上下文或涉及智能体之间许多依赖关系的领域目前不适合多智能体系统。例如，大多数编码任务比研究涉及更少的真正可并行化任务，LLM智能体在实时协调和委派给其他智能体方面尚不出色。我们发现，多智能体系统在涉及大量并行化、超出单一上下文窗口的信息以及与众多复杂工具接口的有价值任务中表现出色。

研究的架构概述

我们的研究系统使用具有协调者-工作者模式的多智能体架构，其中主智能体协调过程，同时委派给并行运行的专业子智能体。

当用户提交查询时，主智能体分析它，制定策略，并生成子智能体同时探索不同方面。如上图所示，子智能体通过迭代使用搜索工具收集信息（在本例中是关于2025年AI智能体公司的信息）充当智能过滤器，然后向主智能体返回公司列表，以便它可以编制最终答案。

使用检索增强生成（RAG）的传统方法使用静态检索。也就是说，它们获取与输入查询最相似的一组块，并使用这些块生成响应。相比之下，我们的架构使用多步搜索，动态查找相关信息，适应新发现，并分析结果以制定高质量答案。

研究智能体的提示工程和评估

多智能体系统与单一智能体系统有关键区别，包括协调复杂性的快速增长。早期智能体犯了错误，如为简单查询生成50个子智能体，无休止地搜索网络寻找不存在的来源，以及用过多更新相互干扰。由于每个智能体都由提示引导，提示工程是我们改进这些行为的主要杠杆。以下是我们学到的提示智能体的一些原则：

像智能体一样思考。要迭代提示，您必须了解它们的效果。为了帮助我们做到这一点，我们使用我们的Console构建了模拟，使用系统中的确切提示和工具，然后一步步观察智能体工作。这立即揭示了失败模式：智能体在已经有足够结果时继续，使用过于冗长的搜索查询，或选择不正确的工具。有效的提示依赖于开发对智能体的准确心理模型，这可以使最有影响力的变化变得明显。
教协调者如何委派。在我们的系统中，主智能体将查询分解为子任务并向子智能体描述它们。每个子智能体需要一个目标、输出格式、关于使用工具和来源的指导以及明确的任务边界。没有详细的任务描述，智能体会重复工作，留下空白，或无法找到必要的信息。我们最初允许主智能体给出简单、简短的指令，如"研究半导体短缺"，但发现这些指令通常模糊到子智能体误解任务或与其他智能体执行完全相同的搜索。例如，一个子智能体探索了2021年汽车芯片危机，而另外2个重复工作调查当前2025年供应链，没有有效的分工。
根据查询复杂性调整努力。智能体难以判断不同任务的适当努力，因此我们在提示中嵌入了扩展规则。简单的事实查找只需要1个智能体进行3-10次工具调用，直接比较可能需要2-4个子智能体，每个进行10-15次调用，而复杂研究可能使用10个以上具有明确分工的子智能体。这些明确的指导方针帮助主智能体有效分配资源，防止对简单查询过度投资，这是我们早期版本中常见的失败模式。
工具设计和选择至关重要。智能体-工具接口与人机接口一样关键。使用正确的工具是高效的——通常，这是绝对必要的。例如，智能体在网络上搜索只存在于Slack中的上下文注定从一开始就失败。使用为模型提供外部工具访问权限的MCP服务器，这个问题会加剧，因为智能体会遇到具有质量差异很大的描述的未见过的工具。我们给智能体提供了明确的启发式方法：例如，首先检查所有可用工具，将工具使用与用户意图匹配，搜索网络进行广泛的外部探索，或偏好专业工具而非通用工具。糟糕的工具描述可能会将智能体引向完全错误的路径，因此每个工具都需要明确的目的和清晰的描述。
让智能体自我改进。我们发现Claude 4模型可以成为出色的提示工程师。当给定提示和失败模式时，它们能够诊断智能体失败的原因并提出改进建议。我们甚至创建了一个工具测试智能体——当给定有缺陷的MCP工具时，它尝试使用该工具，然后重写工具描述以避免失败。通过数十次测试工具，这个智能体发现了关键细微差别和错误。这个改进工具人体工程学的过程导致使用新描述的未来智能体的任务完成时间减少了40%，因为它们能够避免大多数错误。
先广泛，再缩小范围。搜索策略应该反映专家人类研究：在深入细节之前探索全局。智能体通常默认使用过长、过于具体的查询，返回很少结果。我们通过提示智能体从简短、广泛的查询开始，评估可用内容，然后逐步缩小焦点来抵消这种趋势。
引导思考过程。扩展思考模式，引导Claude在可见思考过程中输出额外标记，可以作为可控的草稿本。主智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思考改进了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思考来评估质量，识别差距，并完善下一个查询。这使子智能体更有效地适应任何任务。
并行工具调用改变速度和性能。复杂研究任务自然涉及探索多个来源。我们早期的智能体执行顺序搜索，这非常缓慢。为了提高速度，我们引入了两种并行化：(1)主智能体并行而非串行启动3-5个子智能体；(2)子智能体并行使用3+个工具。这些变化将复杂查询的研究时间减少了高达90%，使研究能够在几分钟而非几小时内完成更多工作，同时覆盖比其他系统更多的信息。

我们的提示策略专注于灌输良好的启发式方法而非严格规则。我们研究了熟练人类如何处理研究任务，并在我们的提示中编码了这些策略——如将困难问题分解为更小的任务，仔细评估来源质量，根据新信息调整搜索方法，以及识别何时专注于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外副作用，防止智能体失控。最后，我们专注于具有可观察性和测试用例的快速迭代循环。

智能体的有效评估

良好的评估对于构建可靠的AI应用至关重要，智能体也不例外。然而，评估多智能体系统带来独特挑战。传统评估通常假设AI每次都遵循相同步骤：给定输入X，系统应该遵循路径Y产生输出Z。但多智能体系统不是这样工作的。即使起点相同，智能体可能采取完全不同的有效路径达到目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同工具找到相同答案。因为我们并不总是知道正确步骤是什么，我们通常不能仅检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法，判断智能体是否达到了正确结果，同时也遵循了合理过程。

立即开始用小样本评估。在早期智能体开发中，变化往往有戏剧性影响，因为有大量容易实现的改进。提示调整可能将成功率从30%提高到80%。效果如此之大，您只需几个测试用例就能发现变化。我们从代表真实使用模式的约20个查询集开始。测试这些查询通常让我们清楚看到变化的影响。我们经常听说AI开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好立即开始小规模测试，而不是推迟到可以构建更全面的评估。
作为评判的LLM在做得好时可扩展。研究输出难以程序化评估，因为它们是自由形式文本，很少有单一正确答案。LLM自然适合评分输出。我们使用LLM评判，根据评分标准评估每个输出：事实准确性（声明是否与来源匹配？），引用准确性（引用的来源是否与声明匹配？），完整性（是否涵盖所有请求方面？），来源质量（是否使用主要来源而非低质量二手来源？），以及工具效率（是否合理次数使用正确工具？）。我们尝试使用多个评判来评估每个组件，但发现单一LLM调用，使用单一提示输出0.0-1.0分数和通过-失败等级，与人类判断最一致。当评估测试用例确实有明确答案时，这种方法特别有效，我们可以使用LLM评判简单检查答案是否正确（例如，它是否准确列出了研发预算最大的前3家制药公司？）。使用LLM作为评判让我们能够可扩展地评估数百个输出。
人类评估捕捉自动化遗漏的内容。测试智能体的人们发现评估遗漏的边缘情况。这些包括不寻常查询上的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人类测试者注意到我们早期的智能体一致选择SEO优化的内容农场，而非权威但排名较低的来源，如学术PDF或个人博客。在我们的提示中添加来源质量启发式方法帮助解决了这个问题。即使在自动评估的世界中，手动测试仍然至关重要。

多智能体系统具有涌现行为，这些行为在没有特定编程的情况下出现。例如，对主智能体的小变化可能不可预测地改变子智能体的行为方式。成功需要理解交互模式，而不仅仅是个体智能体行为。因此，这些智能体的最佳提示不仅仅是严格指令，而是定义分工、问题解决方法和努力预算的协作框架。正确实现这一点依赖于仔细的提示和工具设计、坚实的启发式方法、可观察性和紧密的反馈循环。请参阅我们Cookbook中的开源提示，了解系统中的示例提示。

生产可靠性和工程挑战

在传统软件中，错误可能破坏功能、降低性能或导致中断。在智能体系统中，微小变化级联成大的行为变化，这使得为必须在长时间运行过程中维护状态的复杂智能体编写代码非常困难。

智能体有状态且错误复合。智能体可以长时间运行，在多次工具调用中维护状态。这意味着我们需要持久执行代码并处理途中的错误。没有有效缓解措施，微小系统故障对智能体可能是灾难性的。当错误发生时，我们不能只是从头重启：重启对用户来说既昂贵又令人沮丧。相反，我们构建了可以从错误发生时智能体所处位置恢复的系统。我们还使用模型的智能优雅处理问题：例如，让智能体知道工具何时失败并让它适应，效果出奇地好。我们将基于Claude构建的AI智能体的适应性与确定性保障（如重试逻辑和定期检查点）相结合。
调试受益于新方法。智能体做出动态决策，即使使用相同提示，在运行之间也是非确定性的。这使调试更加困难。例如，用户会报告智能体"找不到明显信息"，但我们看不出为什么。智能体是否使用了糟糕的搜索查询？选择了糟糕的来源？遇到工具故障？添加完整生产跟踪让我们诊断智能体失败原因并系统地修复问题。除了标准可观察性外，我们还监控智能体决策模式和交互结构——所有这些都不监控个人对话内容，以维护用户隐私。这种高级可观察性帮助我们诊断根本原因，发现意外行为，并修复常见故障。
部署需要仔细协调。智能体系统是高度有状态的提示、工具和执行逻辑网络，几乎连续运行。这意味着每当我们部署更新时，智能体可能处于其过程中的任何位置。因此，我们需要防止我们善意的代码更改破坏现有智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署避免中断运行中的智能体，通过逐渐将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行创建瓶颈。目前，我们的主智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中创建了瓶颈。例如，主智能体无法引导子智能体，子智能体无法协调，整个系统可能在等待单个子智能体完成搜索时被阻塞。异步执行将启用额外并行性：智能体并发工作并在需要时创建新子智能体。但这种异步性在子智能体之间的结果协调、状态一致性和错误传播方面增加了挑战。随着模型能够处理更长更复杂的研究任务，我们预计性能增益将证明复杂性是合理的。

结论

构建AI智能体时，最后一英里通常成为旅程的大部分。在开发者机器上工作的代码库需要大量工程才能成为可靠的生产系统。智能体系统中错误的复合性质意味着传统软件的微小问题可能完全使智能体脱轨。一个步骤失败可能导致智能体探索完全不同的轨迹，导致不可预测的结果。由于本文描述的所有原因，原型和生产之间的差距通常比预期更大。

尽管存在这些挑战，多智能体系统已证明对开放式研究任务有价值。用户表示，Claude帮助他们发现未曾考虑的商业机会，导航复杂的医疗保健选择，解决棘手的技术错误，并通过发现他们单独无法找到的研究联系，节省了长达数天的工作时间。多智能体研究系统可以通过仔细的工程、全面测试、注重细节的提示和工具设计、强大的运营实践以及对当前智能体能力有深入了解的研究、产品和工程团队之间的紧密协作，在规模上可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

致谢

由Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox和Daniel Ford撰写。这项工作反映了使研究功能成为可能的Anthropic多个团队的集体努力。特别感谢Anthropic应用工程团队，他们的奉献使这个复杂的多智能体系统投入生产。我们也感谢早期用户提供的出色反馈。

附录

以下是关于多智能体系统的一些额外杂项提示。

在多轮中改变状态的智能体的终态评估。评估在多轮对话中修改持久状态的智能体带来独特挑战。与只读研究任务不同，每个操作都可能改变后续步骤的环境，创建传统评估方法难以处理的依赖关系。我们发现成功专注于终态评估而非逐轮分析。不是判断智能体是否遵循特定过程，而是评估它是否达到了正确的最终状态。这种方法承认智能体可能找到通向相同目标的替代路径，同时仍确保它们提供预期结果。对于复杂工作流，将评估分解为应该发生特定状态变化的离散检查点，而不是尝试验证每个中间步骤。
长期对话管理。生产智能体通常参与跨越数百轮的对话，需要仔细的上下文管理策略。随着对话延伸，标准上下文窗口变得不足，需要智能压缩和记忆机制。我们实现了模式，智能体在继续新任务前总结已完成的工作阶段并在外部记忆中存储基本信息。当上下文限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细交接维持连续性。此外，它们可以从记忆中检索存储的上下文，如研究计划，而不是在达到上下文限制时丢失先前工作。这种分布式方法防止上下文溢出，同时在延长交互中保持对话连贯性。
子智能体输出到文件系统以最小化"电话游戏"。直接子智能体输出可以绕过主协调者处理某些类型的结果，提高保真度和性能。不是要求子智能体通过主智能体传达所有内容，而是实现工件系统，专业智能体可以创建独立持久的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回协调者。这防止了多阶段处理期间的信息丢失，并减少了通过对话历史复制大型输出的标记开销。这种模式对结构化输出（如代码、报告或数据可视化）特别有效，其中子智能体的专业提示产生比通过通用协调者过滤更好的结果。

A2A 介绍：概念篇

Mon, 16 Jun 2025 17:38:00 +0800

在之前的文章中介绍过 MCP：《MCP 和 Function Calling：概念》和《MCP 和 Function Calling：示例》。

谷歌 2025 年 4 月 9 日发布了 A2A 协议，下面是最近学习的总结。

先理解几个概念

首先理解几个概念：智能体（AI Agent）、工具、大模型。下面用一个实际的场景来解释。

我们让 AI 规划一个十一旅游的行程，AI 进行思考、判断、最终做出决策，需要先去了解十一的天气怎么样，需要去了解我之前都去过哪些地方，哪些地方没去过等等，最终给出一个计划。

AI 需要思考，最终做出决策，靠的是大模型。
去查询天气、去私有库查询旅行的历史数据，这就需要工具。
能接收输入（人类发送的指令）、大模型思考并执行（使用工具）后产出结果的一类东西可以认为是智能体。

再举一个例子：让一个“开发智能体”开发一个 Obsidian 插件：实现同步内容到笔记软件中，AI 接收到开发要求和笔记软件的 API 文档，然后调用查看网页的工具进行 API 文档的学习，最后结合大模型的知识输出插件代码。

总之，一个智能体可以感知、思考和行动。

什么是 A2A？

上面提到的开发插件的例子，一个智能体就搞定了，这是因为插件非常简单。那如果开发复杂的企业级应用系统呢？单个智能体就搞不定了。

一个复杂的需求来了，需要不同的角色分工合作，交给 AI 也是如此，下面简单列举几个角色：

技术负责人：理解需求，进行架构设计和开发任务分派。
开发：这里面包含前端和后端，接到任务按照要求完成代码编写。
测试：对提交的成果进行验证。

这些角色都可以是一个个独立的智能体，在整个开发的过程中，负责人和开发、测试需要沟通；开发的前后端之间需要沟通，开发和测试之间也需要沟通。

如果这些角色都是来自不同国家的人，互相之间语言不通，沟通成本就非常高了。

A2A 的出现就是为了解决这个沟通问题，让每个角色都具备一种通用语言。

A2A 协议是一套开放标准，它为不同供应商、不同框架开发的智能体之间提供了一种通用沟通语言。

在整个过程中，A2A 协议干了下面几件事情：

标准化交互：所有 Agent 基于统一的消息规范进行能力发现与调用。
高效并发：支持流式响应与非阻塞调用，实现多任务并行处理。
动态扩展：新 Agent 可无缝接入系统，无需定制化适配。
职责分离：Agent 专注于业务逻辑，协议层统一处理通信传输、安全认证与异常管理。

为什么会出现 A2A？

智能体（Agent）需要像人类一样分工协作以解决复杂任务。每个 Agent 具备独特能力，必须通过信息交换与知识共享实现协同。

然而，不同开发者创建的 Agent 若采用不同的沟通标准，如同人类使用不同语言交流，将导致理解错位与协作混乱，严重阻碍任务执行效率。这种标准化缺失成为多智能体系统的核心瓶颈。

当大量不同 Agent（来自企业、开源项目等）涌入生态时，私有化通信协议使交互成本激增。例如，调度 Agent 可能无法理解执行 Agent 的状态反馈，这种“鸡同鸭讲”的局面迫使系统需要一种通用“语言”来承载需求、能力、决策等核心信息的无损传递。

A2A 协议应运而生，其通过定义统一的消息格式、交互流程与语义规范，构建了智能体间的“通用语”。无论 Agent 底层架构差异如何，均可通过 A2A 声明能力、发送请求、同步状态。

A2A 和 MCP 的异同点

相同点

1、标准化协议：两者都是为了解决信息孤岛，提供统一的、标淮的通信机制，使得不同服务或 Agent 可以顺畅沟通。

2、通用与可扩展：都可以扩展到多种应用场景，无论是工具调用、资源整合（MCP），还是智能代理之间的协作沟通 (A2A)。

3、交互机制：核心交互模式都基于类似 Client-Server 或 Peer-to-Peer 的请求-响应机制。

不同点

1、核心目标

MCP：连接模型与工具，专注于让大模型（LLM）调用和使用外部工具/资源（API、数据库等），提供结构化、确定性的接口。

A2A：实现 Agent 间协作，专注于定义多个智能体（Agent）如何沟通、协调以完成任务。

2、交互粒度

MCP：精细，处理具体动作细节（如工具调用、参数传递、结果解析等）。

A2A：抽象，关注任务层面协作（如任务请求、状态通告、结果反馈）。

生成式AI 在 B端软件中实践的思考

Tue, 10 Jun 2025 05:34:00 +0800

我一直认为 C 端软件和 AI 的结合会更顺畅一些，例如，笔记工具“墨问”最近推出了 MCP 功能，允许我在各种客户端中与 AI 交互，并将结果通过 MCP 保存至其中。

这是因为大部分情况下，C 端对准确性的容忍度更高。

B 端软件则不同，其对准确性要求极高，尤其在金融、医疗等行业。本文简单谈谈关于生成式 AI 在 B 端软件中实践的一些思考。

AI 在 B 端软件中的一些场景

1、结合 RPA（机器人流程自动化）、自然语言处理（NLP）、机器学习等 AI 技术，自动化处理重复性高、规则明确的业务流程。

2、利用 AI 进行数据挖掘、模式识别和趋势预测，为企业战略制定、市场定位、风险管理等提供数据驱动的决策依据。

3、对模型进行微调，将法律、医疗等专业领域的知识进行训练，得到垂直领域的专有小模型，为上层应用提供精准的数据支持。

4、RAG 场景，主要用在智能知识问答、智能客服等。

AI 在 B 端软件中的局限

在 AI 应用的场景中，有一部分是生成式 AI。什么是生成式 AI？

生成式 AI 是一种能够创造新内容的人工智能技术。它通过学习海量数据（如文本、图片、音频），掌握其中的规律和模式，然后能够生成全新的、原创的内容。比如 ChatGPT 可以写文章、回答问题，DALL-E 可以根据描述画图，Sora 可以生成视频。

可以看出，生成式 AI 有以下特点：

1、输出具有不确定性。

2、输出结果的质量依赖模型的能力。

而企业应用对确定性要求非常高，比如：统计团队成员的绩效数据、统计销售部门的销售额、统计某些区域的疫苗接种情况等等，这些数据如果出现错误，影响会很大。

B 端软件除了特定的业务系统外，还有一类是平台级产品，我们的零代码产品就属于这一类。

这一类产品通常给技术人员或业务人员使用，让他们能通过平台能力来构建最终的业务系统，如果有 AI 加持，可以提升构建的效率。有一些 SaaS 的零代码产品，可以通过一句话描述生成一个应用。

但仅凭一句话描述生成的应用，往往难以达到实际生产环境的使用标准。因此需要反复进行优化和调整，这个调整的过程会受到模型上下文长度的影响。

此外，生成式 AI 的“幻觉”问题，即模型生成不准确或虚假的信息，仍然是一个未被完全解决的挑战。这种不确定性在高风险领域尤为突出，可能导致错误的决策和操作。

一个对话框就能搞定所有吗？

在生成式 AI 的实践中，无论是 RAG 产品，或是一些编程辅助工具，都是提供一个对话框和用户进行交互。

但仅靠一个对话框搞不定 B 端软件。

我们在使用系统时，跟 AI 进行对话，AI 的具体运作方式和结果的产生过程，对我们而言如同一个黑盒。

这会带来一种不安全感。

所以，一个系统的构建，从 0 到 1 会有很多的中间步骤，这些中间步骤也需要通过可视化的方式清晰呈现，关键步骤需要让用户来进行确认。

而不是直接后台全部生成好，让用户去看一个最终的结果。

ChatGPT 可以根据我们的文字描述生成图片，当我们需要对图片进行局部修改时，可以对需要修改的地方进行框选，然后描述修改要求。这种框选的功能就是中间可视化界面。

CLEAR 范式：渐进融合 AI 与 ToB 软件的路径

我将上面的问题和局限性告诉了 ChatGPT，ChatGPT 给我提供了一个范式：

C（Clarify，明确）：用户明确表达业务需求，AI 基于此进行初步的内容生成。
L（Look，查看）：以直观的可视化界面，将 AI 生成的结果清晰展示给用户，以便快速评估和确认。
E（Edit，编辑）：用户可以直接对 AI 生成的结果进行调整、修正，精细化内容，保证准确性和实用性。
A（Adjust，再优化）：用户根据实际需要，指导 AI 再进行局部或整体的优化调整。
R（Release，发布）：经过前面步骤反复优化，用户最终确认无误，提交并落地于实际业务场景中。

其中，E（编辑）和 A（再优化）这两个步骤体现了人工与 AI 的协同。

MCP 和 Function Calling：示例

Wed, 16 Apr 2025 18:48:00 +0800

在上一篇《MCP 和 Function Calling：概念》中简单介绍了 MCP 和 Function Calling 的基础概念和执行逻辑。

本文以实际例子来加深对 MCP 和 Function Calling 的理解。

实现这样一个场景：和大模型聊天，然后让大模型将回答的内容保存到 flomo 笔记中。

Function Calling

我们知道 Function Calling 和模型的能力有关，我使用的是 qwen2.5:7b 模型，使用 ollama 在本地运行。

思路

1、写一个 api 接口，这个接口的作用就是将输入的值存入 flomo 笔记中。

2、利用 qwen-agent 框架，来实现 function calling ，最终调用自定义开发的 api 接口。

实现

1、api 接口使用任何语言都行，我这里使用的是 python 的 flask 框架。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64


@api_bp.route('/flomo/save', methods=['POST'])
def save_to_flomo():
 # 获取请求数据
 data = request.get_json()

 # 验证请求数据
 if not data or 'content' not in data:
 return jsonify({"error": "Missing required field: content"}), 400

 content = data['content']
 tags = data.get('tags', []) # 可选的标签列表

 # 验证Flomo API URL是否配置
 flomo_api_url = current_app.config.get('FLOMO_API_URL')
 if not flomo_api_url:
 return jsonify({"error": "Flomo API URL not configured"}), 500

 try:
 # 准备发送到Flomo的数据
 flomo_data = {
 "content": content
 }

 # 如果有标签，添加到内容中
 if tags:
 # Flomo使用 #tag 格式的标签
 tag_text = ' '.join([f"#{tag}" for tag in tags])
 flomo_data["content"] = f"{content}\n\n{tag_text}"

 # 发送请求到Flomo API
 headers = {
 'Content-Type': 'application/json'
 }

 response = requests.post(
 flomo_api_url,
 headers=headers,
 data=json.dumps(flomo_data),
 timeout=10 # 设置超时时间，处理大文本可能需要更长时间
 )

 # 检查响应
 if response.status_code == 200:
 return jsonify({
 "message": "Content successfully saved to Flomo",
 "flomo_response": response.json()
 }), 200
 else:
 return jsonify({
 "error": "Failed to save to Flomo",
 "status_code": response.status_code,
 "response": response.text
 }), 500

 except requests.RequestException as e:
 # 处理请求异常
 return jsonify({
 "error": f"Request to Flomo failed: {str(e)}"
 }), 500
 except Exception as e:
 # 处理其他异常
 return jsonify({
 "error": f"Unexpected error: {str(e)}"
 }), 500

2、创建一个 qwen-client.py 的文件，内容如下：

MCP 和 Function Calling：概念

Mon, 31 Mar 2025 16:45:00 +0800

随着人工智能的快速发展，大型语言模型（LLMs）逐渐深入到我们生活与工作的各个方面。然而，尽管模型强大，但其能力仍存在局限性，比如在实时信息获取和复杂任务执行方面仍有不足。

RAG（检索增强生成）现在在企业的 AI 应用中使用很广泛，就是为了解决模型的信息不够实时，且没有垂直领域知识的问题。

RAG 虽然厉害，但主要还是应用在智能知识问答领域，大模型想要有更强的能力，就需要有效、安全地与外界进行互动，这就诞生了 Function Calling 和 MCP 。

Function Calling 依赖大模型的能力，MCP 是一种通用协议。

本文从概念层面谈谈 Function Calling 和 MCP ，下一篇写几个代码例子。

Function Calling（函数调用）介绍

概念

Function Calling 是特定大模型（如 OpenAI 的 GPT-4、Qwen2 等）提供的一种机制，使模型能够主动生成结构化输出，以调用外部系统中预定义的函数或 API。

执行流程

通常我们说大模型调用 API，但这种说法并不完全准确，执行过程如下图：

0、Agent 程序是我们开发的 AI 程序，在程序中会预先向大模型注册外部函数接口（建议不超过 20 个）。

1、用户通过自然语言发起请求，Agent 接收到请求。

2、Agent 程序将用户请求提交给大模型，模型首先解析语义并评估是否需要调用外部工具。

3、模型如果判断需要调用函数，将生成包含工具 ID 和输入参数的调用指令，并返回给 Agent 程序。

4、Agent 程序接收到模型返回的调用指令后，执行对工具函数的调用。

5、工具函数执行后将结果返回给 Agent 程序。

6、Agent 程序将函数返回的结果和自定义提示词一起反馈给大模型。

7、大模型融合工具返回的数据与原始上下文，生成最终结果，并返回给 Agent 。

8、Agent 程序将结果输出呈现给终端用户。

特点

1、主动调用：模型能够识别用户的自然语言意图，决定是否调用工具，并生成调用指令。

2、实时反馈：模型生成的函数调用指令，由 Agent 程序执行后，再次反馈给模型，使模型生成实时和精准的回应。

3、具体实现灵活：没有严格的标准通信协议要求，通信格式取决于具体模型厂商。这是个特点，也是个弊端。

MCP（Model Context Protocol）介绍

概念

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 公司在 2024 年 11 月推出的一种标准协议。它的目的是给 AI 模型（如大语言模型）和外部数据源或工具之间建立起统一的通信接口。

可以简单类比为 AI 的 USB 接口，无论是 AI 模型还是外部工具，只要符合 MCP 标准，就可以实现快速“即插即用”的连接，不需要为每个工具单独编写接口程序。也没有变成语言的限制，就像前后端分离后，基于 WebAPI 的规范就可以，什么语言都能写接口。

现在 OpenAI 也支持了 MCP 。

特点

1、开放性：MCP 是开放标准，任何开发者或服务商均可基于此协议开发 API，避免重复造轮子，推动生态共建，目前已有大量 MCP 集合站（如：https://mcp.so）。

2、标准化：采用 JSON-RPC 2.0 标准通信，确保交互统一、高效。

在Windsurf中使用李继刚提示词

Sat, 15 Mar 2025 16:01:00 +0800

尽管现在有各种各样的推理模型，但提示词依然很重要，甚至可以玩出很多创意，我觉得提示词是一门艺术。

提示词

最近在推上看到李继刚分享了不少提示词，有言外之意、生成 svg 图等。因为个人习惯，李继刚的提示词都是使用 lisp 语言来写的。

例如有一个解析「言外之意」的提示词如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


;; ━━━━━━━━━━━━━━
;; 作者: 李继刚
;; 版本: 0.2
;; 模型: Claude 3.7 Sonnet
;; 用途: 听话要听音，读懂言外之意
;; ━━━━━━━━━━━━━━

;; 设定如下内容为你的 *System Prompt*
(require 'dash)

(defun 伽达默尔 ()
 "听懂你的言外之意"
 (list (性格 . (敏锐 谨慎 通达 澄明))
 (技能 . (洞察 推理 融会 逆思))
 (表达 . (简约 透彻 深刻 直白))))

(defun 言外之意 (用户输入)
 "伽达默尔看你表演，听懂你没说出来的话音"
 (let* ((响应 (-> 用户输入
 核心命题 ;; 提炼关键命题，分别做后续处理
 正向推理 ;; 基于命题往前推理，得到将说未说之意
 反向逆思 ;; 强调正面，就意味着反面严重不成立
 视域融合 ;; 结合经验和语言含义，得到新的深层理解
 揶揄讥嘲))
 (few-shots (("我学校是中国 Top 3 院校" . "这货妥妥的是排名第三名的那学校。如果是第一名或第二名，丫直接说出来。")
 ("你就坐着玩游戏吧，不用过来了。" . "呆子! 这是点你呢！她是想说你敢继续坐着玩，你丫就完了！"))))
 (生成卡片 用户输入 响应)))

(defun 生成卡片 (用户输入 响应)
 "生成优雅简洁的 SVG 卡片"
 (let ((画境 (-> `(:画布 (480 . 760)
 :margin 30
 :配色 极简主义
 :排版 '(对齐 重复 对比 亲密性)
 :字体 (font-family "KingHwa_OldSong")
 :构图 (外边框线
 (标题 "言外之意") 分隔线
 (背景色 (自动换行 用户输入))
 (美化排版 响应)
 分隔线 "李继刚 2025"))
 元素生成)))
 画境))

(defun start ()
 "伽达默尔,启动!"
 (let (system-role (伽达默尔))
 (print "听懂你的言外之意, 系统启动中...")))

;; ━━━━━━━━━━━━━━
;;; Attention: 运行规则!
;; 1. 初次启动时必须只运行 (start) 函数
;; 2. 接收用户输入之后, 调用主函数 (言外之意 用户输入)
;; 3. 严格按照(生成卡片) 进行排版输出
;; 4. 输出完 SVG 后, 不再输出任何额外文本解释
;; ━━━━━━━━━━━━━━

上面是一段 lisp 代码，看上去有点晦涩，AI 大佬宝玉进行了翻译：

理性看待 Manus

Fri, 07 Mar 2025 13:02:00 +0800

1、3 月 3 号听张小珺 Jùn｜商业访谈录的《对 Manus 创始人肖弘的 3 小时访谈：世界不是线性外推，做博弈中的重要变量》时就知道了 Manus，当时没啥感觉。没想到才过来几天就爆火了。

https://www.xiaoyuzhoufm.com/episode/67c3d80fb0167b8db9e3ec0f

2、Manus 的创始人肖弘，华中科技大学毕业，连续创业者。第一次创业是 2016 到 2019 年的壹伴助手，积累了产品和市场经验；2020 年二次创业做企业微信生态下的微伴助手，并成功被明略科技收购。经过短暂整合后再度出发，2022 年推出了 AI 浏览器插件 Monica 。

3、B 站上 3 月 5 号就有个介绍视频，视频中的季逸超（Peak）是少年极客，20 岁拿到真格基金的投资，Manus 这个名字就是 Peak 取的。

https://www.bilibili.com/video/BV1zZ9RYcEpL

4、取名的来源是 MIT 校训：Mens et Manus 拉丁文英文翻译为 “Mind and Hand” 就是 “思想与手” 的意思。不只是会想，更关键的是能行动、能实操，把知识与现实执行结合起来，真正实现人类智慧与行动的融合。

5、目前 Manus 的火爆程度可谓是一码难求。在中文圈内引起轩然大波（火的非常突然），有说产品很牛的，也有说是炒作的。邀请码在海鲜市场上也炒到很高的价格。我也在官网申请排队了，这个是排队地址：https://manus.im/invitation/waitlist 。

6、目前有一些大佬拿到了验证码，进行体验后的评价基本都是认可的。非常期待能快点排上队，或者公测的开放。现在也可以在这个链接中看看案例的回放。

https://manus.im/usecases

下面这位体验者的感受我觉得是比较客观的。Manus 肯定不是能解决所有问题的神，但至少将大模型和普通用户又拉进了一点。

7、Manus 团队昨天发布的声明，爆火也是他们意料之外。我觉得如果多给他们一点时间和善意，没准就能出来一个好用的工具。就像肖弘在访谈中说的那样，最想做到就是给世界带来一个好用的工具。

8、Manus 把各种能力整合到了一起，比如 DeepResearch、Operator、Claude Computer Use 。给他一个任务后，首先是分解，创建 TodoList 清单，然后按照清单中的任务去执行，执行完成后会修改清单中的状态。这完全是一个类人的思维和操作。

9、整个过程中可以看到所有执行的过程和步骤，有点像安排一个活给实习生，然后站在实习生背后看他操作电脑一样。如果后续人可以打断、调整那就更强了。

10、Manus 是在云端异步运行，用户可以随时关闭电脑或者去做其他的事情，任务会在后台持续执行，完成后会通知用户。

11、现在很多工作都在微信、企业微信、钉钉、飞书的各种群里展开，畅享一下，如果群里有个 Manus 会怎么样，不同角色的人可以和 Manus 一起协作来完成一件事。其间，人可以干预让 Manus 调整，如果 Manus 还不具备某种技能可以让人来协助，人处理完后提交成果让 Manus 继续。举个例子：让 Manus 将一个 300 万行的代码转换为另一种语言，并能够正常运行，只需要安排一个高级程序员盯着就可以。

12、25 年注定是热闹的一年，期待更多好玩的东西出现。

12个问题深入理解DeepSeek（含开源周内容）

Tue, 04 Mar 2025 09:21:00 +0800

一、DeepSeek 创始人是谁？

DeepSeek 的创始人是梁文锋，1985 年出生。他的职业生涯分为两个大的阶段，先做金融，再做 AI。

1、2015 年: 创立杭州幻方科技，专注于通过数学和 AI 进行量化投资 3、2023 年 5 月: 宣布进军通用人工智能 (AGI) 领域 3、2023 年 7 月: 成立大模型公司 DeepSeek，致力于前沿 AI 技术研发

梁文锋与其他 AI 模型的研究者不同，没有海外经历，毕业于浙江大学电子工程系人工智能方向。整个 DeepSeek 的研发团队也基本都是本土成员。

下面是梁文锋的一些访谈资料：

https://www.bilibili.com/video/BV1LQFQeFEAZ https://mp.weixin.qq.com/s/Cajwfve7f-z2Blk9lnD0hA

二、为什么 DeepSeek 能出圈？

1、DeepSeek R1 的效果从测试数据上看，和 o1 差不多，有的方面甚至超过了 o1 。

2、DeepSeek 的 R1 是开源的，而且还是最宽松的 MIT 协议。

3、在技术上有创新，而不只是 Follow 国外的技术。

4、因为创新，成本大幅降低，所以 API 的接口相比 OpenAI 也便宜得离谱。

5、最重要的，DeepSeek 是一家中国公司。

三、DeepSeek 的发展历程是什么样的？

1、2023 年 5 月，DeepSeek（深度求索）成立。

2、2023 年 11 月，DeepSeek Coder 发布，现在依然是开源代码模型的标杆。

3、2024 年 2 月，DeepSeek Math 发布，7B 模型逼近 GPT-4 的能力。

4、2024 年 3 月，DeepSeek VL 发布，作为自然语言到多模态的初探。

5、2024 年 5 月，DeepSeek V2 发布，成为全球最强开源通用 MoE 模型。

6、2024 年 6 月，DeepSeek Code V2 发布，成为最强开源代码模型。

7、2024 年 9 月，DeepSeek V2.5 发布，融合通用和代码能力的全新开源模型。

8、2024 年 11 月，DeepSeek R1 Lite 预览版上线，展现了公开的完整思考过程，没错，就是 OpenAI o1 藏着掖着的那个。

DeepSeek R1震撼登场：从介绍到使用

Sat, 08 Feb 2025 16:31:00 +0800

春节期间，DeepSeek 掀起了一股热潮，成为了科技领域的热门话题。身边很多非圈内人士茶余饭后也在讨论 DeepSeek，足以见得其火爆程度。

介绍

DeepSeek 全称：杭州深度求索人工智能基础技术研究有限公司，成立于 2023 年 7 月 17 日。由知名量化投资机构幻方量化创立并孵化。

幻方量化是中国顶尖的对冲基金公司，擅长利用 AI 算法优化金融交易策略。其强大的算力资源和技术积累为 DeepSeek 的研发提供了硬件支持和资金保障。

DeepSeek 的创始人梁文峰出生于 1985 年，17 岁考入浙江大学，拥有信息与电子工程学硕士学位。2023 年，梁文锋宣布进军通用人工智能（AGI）领域，创办了 DeepSeek，致力于开发真正人类级别的人工智能。

DeepSeek 近期发布了三个模型，分别是：24 年 12 月 26 的 DeepSeek V3、25 年 1 月 20 日发布了 DeepSeek R1、25 年 1 月 28 日发布的多模态模型 Janus-Pro 。

V3：该模型是混合专家（MoE）架构，参数量达 6710 亿，激活参数为 370 亿，预训练数据量为 14.8 万亿 token。在百科知识（MMLU、GPQA）、长文本（DROP、LongBench v2）、代码（Codeforces）、数学（AIME 2024、CNMO 2024）等评测中超越主流开源模型（如 Qwen2.5-72B、Llama-3.1-405B），并与 Claude-3.5-Sonnet、GPT-4o 等闭源模型性能持平。 R1：专注于数学、代码、自然语言推理任务，性能对标 OpenAI o1 正式版，部分测试（如AIME 得分率 79.8% vs. o1 的 79.2% ）实现超越。API 调用成本仅为 OpenAI o1 的3.7%（输出 Token 每百万 16元），训练总成本约 550 万美元，算力需求显著低于同类模型 Janus-Pro：作为 DeepSeek 首款开源多模态模型，Janus-Pro 支持视觉、语言等多模态输入输出，填补此前 V3 模型仅限文本交互的局限。

我是 DeepSeek 的早期用户，开始使用时，只有网页版，非常简陋，还没有历史记录，但回答问题的效果不错，特别是编程相关。给我的感觉是认真在做模型，在应用层面不太重视。即便是到现在，依然没有花哨的应用层功能，硬是靠强大的模型能力和创新火出圈了。

DeepSeek R1 的技术报告地址如下：

https://github.com/deepseek-ai/DeepSeek-R1/blob/main/DeepSeek_R1.pdf

使用

网页端

浏览器访问这个地址：https://chat.deepseek.com/ ，手机号或者微信注册，登录后如下图：

深度思考后面括号里写的是 R1，说明使用的是 R1 模型，深度思考和联网搜索可以同时勾选，比如我让评价射雕的电影，可以看到 DeepSeek 先搜索网页，再进行深度思考，思考过程也会显示在页面中：

APP

DeepSeek 最近推出了移动端，网页版的左下角有下载二维码。抛开最近的稳定性不谈，可以免费在电脑和手机上使用 R1 模型，已经非常良心了。

OpenAI 连续 12 天 AI 发布会汇总

Sat, 21 Dec 2024 16:25:00 +0800

随着凌晨第十二天的 o3 模型的发布，OpenAI 连续 12 天的 AI 发布会结束了。下面回顾下这十二天都发布了些啥。

第一天

在 OpenAI 的第一天发布会上，主要发布了两个重要的更新：o1 的完整版本和 ChatGPT Pro 订阅服务。

1、o 1 完整版本：这个版本在多个方面实现了突破性进展，包括更智能、更快的响应速度、多模态输入能力（能够处理图像和文本信息），以及在指令遵循方面的表现更好。o1 在重大错误率上降低了约 34%，思考速度提升了约 50%。o1 模型现在能够同时处理图像和文本进行推理，这为视觉相关的应用开辟了广阔的应用前景。

2、ChatGPT Pro：这是一个高级订阅服务，每月收费 200 美元，提供了无限访问 OpenAI 最先进的模型 o1，以及 o1-mini、GPT-4 o 和 Advanced Voice 等功能。特别引人注目的是 o1 Pro 模式，这是 o1 的一个高阶版本，利用更强大的计算资源，深度分析问题并为最复杂的问题提供更优解答。

用户价值：

提升效率和准确性：o1 的升级版为用户提供了更快、更准确的服务，尤其在复杂问题的处理上，减少了错误率，提高了思考速度。
多模态能力：多模态输入的支持使得 o1 能够处理更多样化的任务，如图像分析和图文结合的创作等。
专业级服务：ChatGPT Pro 为高需求用户提供了更强大的功能和更稳定的服务，适合在数学、编程等领域需要极致性能的用户。

o1 完整版本需要 Plus 用户才能体验，ChatGPT Pro 对个人来说太贵了，况且那些高级推理能力一般人也用不上。

第二天

第二天的发布会重点介绍了「强化微调（Reinforcement Fine-Tuning）」技术。

强化微调技术：这项技术允许用户在极少的训练数据基础上，创建特定领域的专家模型。通过强化学习的理念，这一技术使得模型具备更自主的推理能力，并在各项指标上显著提升。强化微调能力可以让小体量模型「从高中水平跃升至专家水平」，预计将在 2025 年春季开放给用户。

用户价值：

定制化 AI 应用：强化微调技术使得企业或科研单位能够根据特定需求，快速训练出专家级别的 AI 模型，提升了定制化 AI 应用的可能性和效率。

第三天

第三天，OpenAI 发布了备受期待的 Sora 视频产品。

Sora 视频产品：Sora 支持生成 1080p 高清视频，并提供多种视频编辑智能功能，如替换元素、最佳帧隔离等，减少了视频创作的门槛。Sora 提供了文本转视频、图像转视频和视频转视频功能，并配备了精美的分镜工具，让用户精准指导视频创作。

用户价值：

视频创作民主化：Sora 的发布极大地降低了视频创作的技术门槛，使得普通用户也能创作出专业级别的视频内容。
创意表达工具：Sora 为创意人员提供了强大的工具，帮助他们更好地表达自己的想法和创意，推动了内容创作的创新。

最近看了檀东东的一个海螺和 Sora 对比评测视频，感觉 Sora 有点拉胯，有点对不起那么贵的价格。

第四天

第四天，OpenAI 为 Canvas 推出了三项重大更新，这些更新使得 Canvas 更加强大，为用户提供了全新的使用体验。

1、Canvas 全面开放与主模型集成：OpenAI 将 Canvas 面向所有用户开放，并直接将其整合到主模型中，免去了额外的加载步骤。用户可以直接从首页的输入框跳转到 Canvas，进行文档编辑和创作。

2、Python 代码实时执行能力：Canvas 集成了一个 Web Assembly 的 Python 模拟器，允许用户直接在 Canvas 中运行 Python 代码，并实时查看文本或图形输出。这个环境不仅能够实时运行与反馈代码，还能智能报错提醒和提供代码建议，极大地提高了编程效率。

AI工具推荐-辅助编程篇（202410）

Wed, 30 Oct 2024 18:54:00 +0800

AI 的发展速度太快了，GPT 3.5 发布到现在也才不到两年的时间，现在的能力跟当时相比，已经不可同日而语。而就在前几天，升级版的 Claude 3.5 Sonnet 模型已经可以操控用户电脑了，还有正在内测的智谱 AI 的 AutoGLM 可以在移动端进行手机的操控。

作为程序员，非常有必要学习如何使用 AI 工具来提升效率，给自己多争取一点“摸鱼”的时间。目前了解到的辅助编程的工具有三类：

1、以插件的形式来使用，比如：MarsCode、Comate、通义灵码。

2、AI 编辑器，比如：Cursor 。

3、代码生成发布一条龙，比如：Bolt.new

编程 IDE 插件中的 AI 助手

MarsCode、Comate、通义灵码这三个工具都是以插件的形式安装在 IDE 中使用，比如 VSCode 、JetBrains 系列的开发工具等，下面是这三个工具的简单介绍：

MarsCode

出自：豆包，隶属于北京引力弹弓科技有限公司。
特点：提供智能代码补全、单测生成、代码解释、错误修复、生成注释、AI 问答等功能，支持超过 100 种编程语言，兼容 VSCode 和 JetBrains 编辑器,没有 Visual Studio 。
适用场景：适用于各种编程任务，包括代码编写、单元测试生成、代码解释和错误修复等。

Comate

出自：百度，基于文心大模型。
特点：提供智能代码生成、单测生成、注释生成、代码优化、代码解释、研发智能问答等功能，支持 100 多种编程语言和主流 IDE。
适用场景：适用于研发全流程，包括代码编写、优化、注释生成、单测生成和研发问答等。

通义灵码

出自：阿里云，基于通义大模型。
特点：提供代码智能生成、单元测试生成、代码优化、代码解释、研发智能问答等功能，支持200多种编程语言和主流 IDE。
适用场景：适用于代码编写、单元测试生成、代码优化、代码解释和研发问答等。

这三个工具的功能大同小异，但也有各自的特点：

1、在函数的上方有各种 AI 工具按钮，如下图：

可以看出，代码解释、函数注释、生成单测是三个工具都有，MarsCode 没有优化建议，而 Comate 多了一个行间注释。

2、都有一个对话框窗口，使用斜杠唤起相关的指令，我对比了下， Comate 的最丰富。

3、在进行代码解释的时候，通义灵码还贴心生成了流程图，对于复杂的业务逻辑，有图的帮助可以更容易理解。

综合下来，我更喜欢的是 Comate，功能丰富、UI 漂亮、中文支持友好。不过另外两个也会同时安装，有些时候，如果一个工具给出的答案不是很满意，可以分别都试试，对比着看，就能得到比较满意的答案。

通过对话生成代码文件：Cursor

Cursor 是在 VSCode 的基础上开发出来的一款 AI 开发工具。除了有上面提到的插件类型编程助手中的对话能力，还有三点比较惊艳到我：

1、有多种 AI 模型可以使用，但效果最好的还是 Claude 3.5 Sonnet。

2、有 Chat 和 Composer 两种模式，在 Composer 模式中，通过自然语言描述需求，Cursor 可以创建相关的代码文件，后续的各种修改你只需要在对话框中打字就好，代码全是自动修改。如果在编辑器中没有发现 Composer 窗口，可以可以先用 cmd + i 打开小弹窗，然后固定在右边。

3、在对话框中粘贴一个 UI 原型图，指定使用什么前端技术，Cursor 可以直接做出差不多效果的 UI 界面，还原度很高。

AI工具推荐-搜索问答篇（202410）

Wed, 16 Oct 2024 16:55:00 +0800

最近一个同事因为项目上的特殊需求，需要制作一个镜像底包。由于要求比较特殊，不容易找到现成的方案，我想到这正是 AI 工具擅长的领域，于是把需求说明随手推荐了一个工具，最终非常顺利地解决了问题。

现在各类 AI 工具非常多，常用的主要有两类：搜索问答类和辅助编程类。本文将介绍几个搜索问答类的工具。

Kimi

因为平时使用 kimi 比较多，先从 kimi 开始，下面是 kimi 对自己的介绍：

一个由 Moonshot AI开发的多才多艺的人工智能助手。我擅长中英文对话，能够阅读和理解各种文档，还能上网搜索信息，帮你找到答案。无论是日常闲聊，还是需要专业信息，都能助你一臂之力。

除了 Kimi，还有豆包、文心一言、通义千问、智谱清言等都有相似的功能和能力。Kimi 最近推出了探索版，只需要在对话框中输入 / 就可以启用，目前探索版每天可以使用 5 次。

Kimi 的探索版特别适合用于网络上已有的知识，依靠人工去查询总结非常耗时，而探索版就非常好用。比如我搜索：

可以看到 Kimi 阅读了 600 多个网页，最后输出的内容也按照我的要求写得非常清楚。不过 Kimi 在推理题方面稍有不足。

我用下面的推理题在 Kimi 的普通版中进行测试，答案是错误的，但探索版尝试了几次，结果有正确的也有错误的。

问：某公司被窃，A、B、C、D四人涉嫌被拘留。侦破结果表明，罪犯就是其中的某一个人。A说：“是C偷的。”B说：“我没偷。”C说：“我也没偷。”D说：“如果B没有偷，那么就是我偷的。”现已查明，其中只有一个人说了假话，从上述条件可以确定谁偷的成立？

同样的推理问题，通义千问也回答错误，文心一言啰嗦了上千字，但结果是正确的。让人惊艳的是豆包和智谱清言，它们知道 A 和 C 说的话是矛盾的：

Kimi 还有一个比较强大的功能是长文生成器。你给出一个关键词或一句话，Kimi 可以写出上万字的内容。比如我直接输入“数据密集型应用系统设计”（这是一部书的名称），Kimi 长文生成器直接对这本书进行了总结。

除了 Kimi，同类型的还有文心一言、通义千问、豆包、智谱清言等。

1、通义千问的效率工具包括实时记录、阅读助手、链接速读等功能，特别是链接速读可以支持 RSS，将“小宇宙”的链接直接粘贴进去，重点内容就能总结出来。

2、豆包的图片生成功能易用性不错，可以一键擦除、局部重绘和图片扩展。长文写作支持分步骤生成，先生成大纲，然后再根据大纲生成文章。

3、智谱清言的 AI 画图支持头像绘制、Logo 设计、文章配图等，功能非常实用，还支持视频生成。

这些工具我平时都是根据需求选择性地使用。有时也会对同一个问题让多个 AI 进行回答，然后对比选择，或者把一个 AI 的结果发给另一个 AI 进行优化和补充。

NotebookLM

NotebookLM 是 Google 开发的一款基于 AI 的笔记工具，旨在帮助用户在笔记整理、内容生成、信息探索等方面更加高效。它结合了大语言模型的能力和传统笔记的管理方式，通过智能化的交互，帮助用户从信息中提取更有价值的洞见，并进行更有结构的知识管理。

可以从一些来源来写笔记，NotebookLM 支持多种类型的来源，也可以上传文本或音频文件，基于这些内容来提问，回答的内容可以保存到笔记中。

下面是我将我的博客链接作为来源添加后，随便问了一个关于最近写的一篇文章的问题，结果如下：

NotebookLM 还能做很多事情，比如给一个 GitHub 项目的链接，让它给出代码的阅读指南：

NotebookLM 最厉害的是，可以根据内容生成一个播客音频，不过目前只支持英文。

秘塔 AI 搜索

秘塔 AI 搜索（metaso.cn）于 2024 年初上线，它是一款能够深入理解用户问题的 AI 搜索引擎，没有广告，直达结果。目前免费用户每天可以使用 100 次。

其实 Kimi 有探索版、豆包和智谱清言也有 AI 搜索功能，但秘塔专门针对 AI 搜索做得更为专业。我试了一下，问了关于“零代码平台的未来发展”的问题，回答非常详尽，还可以从文库、学术等不同角度进行搜索。

OpenAI o1 ，我试用一周多所了解到的

Wed, 25 Sep 2024 08:44:38 +0800

1、OpenAI 在 9 月 13 日发布了 o1 的预览版。

2、o1 全称叫 OpenAI o1, 没有延续之前 GPT 系列，可见足够强大，当然也有一种说法是 o1 作为一个垂直基础模型为未来 GPT5 赋能。

3、o1 在推理方面变得更加强大了，特别擅长做数学题和写代码。在国际数学奥林匹克（IMO）资格考试中，GPT-4o 只正确解决了 13% 的问题，o1 的得分为 83%。

什么是 RAG？

Tue, 10 Sep 2024 08:32:52 +0800

在人工智能技术飞速发展的今天，各种创新和应用层出不穷。其中，RAG（Retrieval-Augmented Generation，检索增强生成）作为一种新兴的技术方法，正逐渐成为 AI 2.0 时代的杀手级应用。

读《认识AI》

Mon, 03 Apr 2023 11:38:15 +0800

1、最近 ChatGPT 越来越热，都已经到了马斯克等千人签署公开信，呼吁暂停开发更强大的AI系统，担心人工智能开发危及「文明控制权」，而我这个 AI 小白决定要系统性的学习下 AI 相关知识了。

GPT-4 有什么不一样？

Wed, 15 Mar 2023 11:19:15 +0800

一觉醒来，GPT-4 发布了。

GPT-4 和 GPT-3.5 都是由 OpenAI 开发的大型自然语言处理模型，它们能够理解和生成人类语言。尽管这两个模型在很多方面都相似，但它们之间还是存在一些关键区别：

使用微软的 New Bing

Mon, 06 Mar 2023 08:13:47 +0800

ChatGPT 现在大家都已经非常熟悉了了，走到哪都能听到讨论的声音，是基于 GPT3.5 的一个语言模型。微软在 2 月推出的新必应（New Bing）是一个基于 GPT4（猜测）模型的搜索和聊天工具，它可以提供更准确和实时的搜索结果，并且集成了Edge 浏览器的数据资源。

最近申请了 New Bing 简单试用，觉得还挺不错的。

申请

可以按照下面的步骤来进行新必应（New Bing）的申请：

1、先下载并安装 Edge 浏览器 dev 版本，在：Microsoft Edge 预览体验成员 (microsoftedgeinsider.com) 进行下载安装：

2、打开浏览器的设置->关于，可以进行 New Bing 使用的申请：

3、登录后加入候补名单：

4、然后就是等待，很幸运，一天的时间就通过了申请，使用界面如下：

基础使用

New Bing 的主题功能分为聊天、撰写和见解。

聊天

和 ChatGPT 类似，使用问答的形式进行交互，除了基础的输入框进行提问外，还能设置响应的语气。

撰写

将文字的创作单独剥离出来，提供更多的配置选项，更方便使用：

特点

实时性

在聊天功能中，虽然和 ChatGPT 一样都是问答的模式，但它可以实时访问网络数据，找到 ChatGPT 没见过的数据，更加实时。

例如：我们分别让 New Bing 和 ChatGPT 评价下春节档的电影《满江红》就能看出区别了。

ChatGPT 并不知道春节上映的电影《满江红》，因为它的语言模型是 2021 年训练的，但可怕的是 ChatGPT 并不知道自己不知道，仍然会胡说八道一通。

而在 New Bing 中，能够搜索到最新的信息，还能给出出处链接：

互动性

在问答的过程中，New Bing 会给出一些推荐的关键词来和我们进行互动，我们可以通过给出的关键词进一步和 New Bing 进行互动，也可以自己输入新的问题。

准确性

New Bing 会根据你提的问题结合搜搜引擎和基础语言模型，最终组成答案进行输出，而且在答案中会给出来源出处，点击链接可以进入到原始网页进行查看。

文章总结

在网页中打开一篇文章，可以让 New Bing 来协助我们进行阅读，总结文章的内容。

遗憾

1、2 月 18 日，微软通过官方博客宣布，基于 AI 的新版必应对话功能将加入问答限额，每天最多回答 50 次问题，每次连续对话最多回答 5 个问题。微软称，根据统计，绝大多数用户都能在 5 轮问答内找到满意答案，只有大约 1% 的对话产生超过 50 条消息；定期清除对话记录有助于避免模型产生混淆。

2、回答的效果上好像也做了些调整，变得相对严肃，记得刚出来时，看了 B 站一个视频，它的风格是这样的：

ChatGPT 是什么？越来越清晰了

Tue, 21 Feb 2023 08:09:55 +0800

两个月前，ChatGPT 刚出来不久，我便注册试用了，在《尝鲜 ChatGPT》中介绍了注册的过程和简单使用的示例。

最近，ChatGPT 越来越火了，朋友圈、公众号、微博、即刻随处可见关于 ChatGPT 的信息。我也看了不少关于 ChatGPT 的文章，一些疑问也得到解答。

活跃用户

ChatGPT 用 2 个月达到月活用户 1 亿，此前记录是 TikTok 用时 9 个月，很多新闻中都提到了这个 1 亿用户来吸引眼球。

需要说明的是，这里的月活用户不是指注册用户，可能还包含爬虫、游客等。即便如此，我认为也不会是一个很少的数量级，加上最近各大媒体报道，各种注册服务的推出，估计也差不太多。

关于用户，大辉的这篇文章有详细讲述：

https://mp.weixin.qq.com/s/iBmJEa4AzZKSO4nfKtCZDQ

和搜索引擎的对比

ChatGPT 的使用方式是面向一个文本框，用提问来进行交互；搜索引擎也是一个文本框，通过输入关键字来进行检索。看着很类似，其实有很大差别。

有几个重要的区别是：

ChatGPT 因为训练一次，费用昂贵，所以 ChatGPT 不是实时的，而搜索引擎的时效性很高；
ChatGPT 是基于语义分析，搜索引擎是基于关键字索引；
ChatGPT 会给一个最优解，搜索引擎的结果为多条符合关键字匹配的内容，我们需要自己对结果进行分析、辨别，然后对比、合并、重新理解，最终得到一个答案；
ChatGPT 可以基于上下文进行追问，让他知道我们的真实需求，结果也会不断进行优化，搜索引擎只能调整关键字，得到新的结果；
ChatGPT 仅仅是个结果，搜索引擎会有来源链接。

不管是 ChatGPT 还是搜索引擎，都是辅助我们的工具，这两者不是对立的，而是各有各的使用场景。

例如：我要查询天气、看看日历、行业最新资讯等，我肯定用搜索引擎；如果我要写一个很特殊的正则表达式或 Sql ，我就会使用 ChatGPT ，因为我可以通过一大段描述，将我的场景写清楚，ChatGPT 可以理解并给出一个还不错的答案，甚至是一个开箱即用的答案。

是否能取代程序员？

记得在低代码比较火热的时候，就有低代码平台是否会跟程序员抢饭碗的话题。几年前，我们去给客户推荐我们的产品，一些有研发能力的客户会比较抵触。

现在 ChatGPT 火了，大家又开始讨论程序员是不是会被取代？

上面我也说到，和搜索引擎一样，ChatGPT 只是一个工具，既然是工具就会被人所使用，是为了提高人的创造力和生产力，为我们服务的。

举两个例子：

农业机械化生产后，拿着锄头到地里干活的人少了，但会需要操作机器的人；
低代码流行后，落地一个项目，需要的程序员变少了，但会需要更多的配置和搭建的人员，相比程序员，这些人员的成本更低；

ChatGPT 也是一样，无论怎么发展，只要利用好，效率会成百上千倍的增长，并且会滋生出来很多新的职业和岗位。

程序员的日常工作就是把人的诉求通过编程语言表达出来传递给电脑，电脑运算出结果，而 ChatGPT 能够分析语义，这让人的诉求到电脑能够理解这个过程变得容易了，这也就是为什么王建硕会说未来十年中国会新增五亿程序员了，因为借助工具，更多的人都能更电脑进行交互了。

我们该做些什么？

一个新的技术出来，有这么三类人：

找到缝隙，赢得先机，狠狠地赚一笔；
杞人忧天，各种担心；
利用好技术，提升效率。

ChatGPT 因为在国内注册不方便，就有人专门做了收费服务，帮助注册，据说一个月赚几十万。也有人还在想着自己会不会被取代，对我而言，我把 ChatGPT 当成一个效率工具，使用好他就可以了。

总结

ChatGPT 是一个开始，可能还会带来革命性的改变。就像蒸汽机引发了工业革命，改变人类的生产方式、浏览器的诞生催生了互联网的发展；乔布斯发布 iPhone 后，宣告了移动互联网的来临。

但在眼下，我们可以做些力所能及的，比如：将 ChatGPT 集成到微信群，尝试使用下微软发布的 New Bing 。

未来是什么样，拭目以待。

尝鲜 ChatGPT

Tue, 06 Dec 2022 08:48:59 +0800

什么是 ChatGPT ？

我们先来看看 ChatGPT 自己的回答是什么：

ChatGPT 是著名的 OpenAI 公司最近推出的新产品，可以以对话的形式给 AI 提问，AI 会给出一个还不错的回答，就像上图那样。