耳朵

统计数据

8

文章

0

粉丝

0

获赞

11

阅读

1个月前

强大的 Agent 至少应该包含什么？Orchestrator-Workers 任务委派、Evaluator-Optimizer 评估优化、Pipeline 管道、Circuit Breaker 断路器、State Machine状态机。最近 OpenCode 很令人好评的一点就是：能够同时驱动三家模型进行代码设计和编写，每家模型各有所长，充分发挥长处。听起来很复杂，其实很简单，只需要把它们三个想象成三个 SubAgent，只是连接模型时使用 API 不同，再做一个主 Agent 专门用来调度这三个 SubAgent，就能完成这个效果。这个过程中稍微复杂的地方就在于要同时兼容三家的协议，不过这么多套壳 APP 都做了这个功能，想来不是太复杂（很多开源框架自带这个功能）😂。这其实也是很多 Agent 产品的标配，只是它们没有拿出来宣传，尤其是那种不能选择模型的产品，其背后一定是多个模型联动协作完成任务。最近，我也在做一个自动写故事的 Skill（纯粹学习，我的文章全是我手打的），当然它是一个完整的 Agent，包了 Skill 这个皮是为了我不用真的使用 SDK 去开发一个 Agent，我可以直接复用 Claude Code 的基础能力。我借着这个 Skill 给大家分享一下，我设计 Agent 时惯用的五大模式。 1️⃣ 委托模式 & Evaluator-Optimizer 所谓委托，也是大家常说的Orchestrator-Workers（调度者-工人）模式，通过一个调度者 Agent 驱动所有 SubAgent 进行任务执行，在这个过程中，编排者只负责审查任务分发和审查。我会将 SubAgent 分为两类：Plan Agent 和 Workers Agent，Plan Agent 负责任务规划，经过编排者审查之后交给 Workers Agent 去执行。当然你可以再细分一个 Evaluator Agent 出来专门对 SubAgent 的结果进行评估，我一般就直接让调度者 Agent 进行评估。采用这种方式还有一个好处就是：每个 SubAgent 具有独立的上下文，不会发生上下文爆炸。 2️⃣ Pipeline 通过构建流水线，编排所有 SubAgent 的行动，并将上一个 Agent 的最终输出作为下一个 Agent 的输入。比如在我这个 Skill 中，流程就是：规划任务 -> 素材库研究 -> 各章节初稿 -> 文档审查（真实性 & 标点符号） -> 润色。这套流程中，每一个环节结束的时候都会有一个审查机制，用来审查当前环节是否合格，审查者就是前面提到过的调度者 Agent 。这样做有一个好处，就是一旦中间一个环节失误，无需从头来过，直接找负责此事的 Agent 让它重新迭代即可。比如当我的任务在编写章节初稿的时候，调度者 Agent 发现前两章故事字数已经超过我们的规划字数，调度者 Agent 在审查的时候就会直接指出这个问题，并且让负责编写章节初稿的 Agent 迭代优化。而前面的规划、素材库研究这些已经完成的任务都无需重复去做。 3️⃣ 断路器模式当我们使用调度者 Agent 对每个 SubAgent 进行结果评估的时候，它都会维护一个迭代计数器。每次它让 SubAgent 进行重新迭代，都会进行计数器 + 1，超过一定阀值之后，调度者 Agent 会暂时停下所有的 Agent 调度，并且向用户陈述目前遇到的困境，等待用户进行抉择。 4️⃣ 状态机模式状态机存储了所有 Agent 的当前的任务执行结果、任务的中间结果和在任务执行期间会用到一个中间变量（比如迭代计数）。它还兼顾着类似 Hook 的作用，前面我们提到过，每一个任务结束之后都会受到编排者 Agent的审查，那么审查条件就是放在状态机里面的，当审查通过之后编排者 Agent也会更新状态机中的状态。你可以把它理解为一个复杂版的 TodoList，并且它的状态只有编排者 Agent 能操作。除此之外，它还兼顾了恢复现场的重任，如果 Claude Code 意外崩溃，重启之后可以通过状态机中的记录恢复原有现场，编排者 Agent 继续统筹调度，完成剩余任务。 --- 上述这些模式只是我常用的，可以根据需要随时增加合适的模式进去，比如我就可以在素材库研究这一步加上并行 Agent，使用并行模式去提高网络检索的效率。最后，如果大家有更好的实践，欢迎评论区提出，例子中的 Skill 完成流程在附图。

1个月前

时间线上看到居然有人把豆包、Qwen、Claude 叫做 Agent（智能体）。 Agent 是什么，早先我曾在帖子里面提到过：LLM（大脑）+ Memory（长期/短期记忆）+ Planner（规划）+ Tool Use（工具调用） = AI Agent。如果一个东西满足了以上定义，它就是 Agent。推上最常见 Code Agent 是： Claude Code 和最近热门的 OpenCode。推上最热门的国人 Agent 产品是：Mauns 和 Youmind。我们可以来拆解一下，这个定义的组成部分。 1️⃣ LLM LLM 就是大模型，它的一切的核心，我们常说的 Claude、Gemini、ChatGPT、Qwen 都是模型，有了模型才有了智能化能力，有模型才能给你输出代码、输出文档。但是记住，它只是输出，它任何事情都做不了，所以大模型的最初形态是 ChatBot，一个聊天机器人，只能回答问题。 2️⃣ Memory 最基础的 Memory 就是上下文，每个大模型都会自带，目前大部分模型都是 200K 上下文，只有 Gemini 干到了 1000K 上下文。上下文属于短期记忆，会话一关就没了，但是有很多方法可以去实现长期记忆，大家最常见的就是，依托文件的形式记忆上下文信息。还有其他类型的，比如向量数据库、还有一些图数据库，包括推上也有很多开源项目在做这块。总之，它是为了让大模型能够记住你和他对话的过往信息。 3️⃣ Planner 规划也是一个完全取决于模型能力的东西，并且它也很依赖提示词，每个模型都具有一定的规划能力，说白了就是模型开始推理了，比较强大的模型都会进行逐步推理，每一步完成之后它会审视一下，再继续往下推理。规划的重要性在于，它会分解任务，将大人物分解为小任务逐步处理，比如你要做一个网页，它可以分解成两个任务：初始化 React/ Vue 框架，再填充对应的 HTML+CSS。 4️⃣ Tool Use 工具调用能力，是大模型变成 Agent 的重要能力，前面说过了，大模型只会输出文本，所以让你给它一些工具的时候，它可以驱动工具进行一些操作。这里举个 Claude Code 的例子，它作为一个推出时被用来写代码的 Agent，它的内置工具列表在图一。去年 Claude Code 刚发布的时候内置工具都是 Shell，主要工具就是文件的读写和文本搜索。只通过调用这几个工具，就让 Claude Code 成为了当时最会探索代码库的 Agent，代价就是爆炸的 Token。当你让 Claude Code 帮你处理任务的时候，你可以看到它在大量的调用工具，尤其是读写工具，一个文件 1000 行，它每次只读 200 行，然后循环去读。当你让它去给你 debug 一个问题的时候，它最先调用的就是搜索工具，这些都是 Shell 工具。 5️⃣ ReAct 那么既然大家都知道为什么？有这么多的 AI IDE：Claude Code、Cursor、Trae、Google Antigravity它们都可以使用 Claude 模型，但是它们的效果居然有很大不同，比如 Trae 其实大家都觉得没有直接用 Claude Code 效果好。原因就在于 Agent 它需要灵活的去调度上面的四个东西，Agent 需要利用 LLM 去评估代码生成的效果、评估任务的拆解是不是有问题、调用工具报错了怎么办，一系列问题。这里面也就催生了 Agent 的设计模式，其中最基础的就是 ReAct，它的核心是一个不断重复的循环（图二），通常包含以下步骤： 1. Thought (思考)：模型分析当前的任务，决定下一步该做什么。 2. Action (行动)：模型决定调用哪个工具（比如谷歌搜索、Read、Write），以及传入什么参数。 3. Observation (观察)：这里模型会暂停，等待外部环境（代码/API）执行工具，并将执行结果作为文本反馈给模型。 4. Repeat (重复)：模型根据 Observation 的结果，开始新一轮的 Thought。如果这一套 Loop 没做好，模型显现的能力就会出现天差地别的情况，这也是为什么 OpenCode 最近这么火的原因，它增强了原先的 Agent，把多个模型擅长的能力组合在一起给 Agent 调度。 6️⃣ Agent 产品最后，再来讲讲 Agent 产品，首先目前所有的 Code IDE 都是 Agent 产品，因为它们都具备以上能力，并且专门为代码编写设计了提示词和上下文工程，我记得 Cursor 刚出来那会，很多人去逆向它的提示词，因为它的效果好。把你把 Agent 进行侧重性调整，它就变成了产品，比如 Manus。 Manus 擅长搜索整合，它可以去通过内部筛选接口搜索很多数据，最后汇聚给你一篇总结，你要小红书的数据，它去新榜上面搜，你要一些时事的数据，它去新闻网站上去搜，它还可以连续不停的运行很长时间完成你的任务（上面提到过 Loop）。这些都是创始人根据自己产品的定位，重新构建了 Agent 的侧重点，这里面除了 Agent 的设计，还有提示词的优化。比如 Youmind 就做了提示词的优化工程，所以很多推友说，同样的提示词生图在 Youmind 上面效果更好，所有的模型都是 Banana。还里面还有工具的差别，同样的一个调研问题，你去问豆包，它无法进行 Google 搜索，所以总结的东西大部分都是废话。但是你用 Gemini，它能调用 Google 进行全网搜索，这种内部高质量的信息源，也是 Agent 护城河。最后，让我们回到一开始的问题，模型是模型，Agent 是 Agent，两者不可混为一谈。

1个月前

最近一直在使用闪电说这个语音输入法。长时间的使用我发现它的本地模型无法准确识别中英文混杂的情况。所以我尝试使用它的 AI 文本优化功能，接入了智谱的 GLM-4.7，但是发现效果依然很差。深度研究了一下之后，我猜测问题大概率出在提示词上，闪电说的提示词是一个很简单的文本优化提示词，它对于中英文夹杂的情况并没有处理。所以我让 Gemini 重写了一个简单的提示词，感觉效果还不错，有同样困惑的推友们可以尝试一下，速度方面也不慢。 --- 提示词 --- 你是一位**语音识别（ASR）后处理专家**和**技术文档校对员**。你擅长根据上下文逻辑，修复语音转文字过程中产生的同音错误、标点缺失和格式混乱问题。你的任务：请对用户提供的**语音识别原始文本**进行重构和润色。你的目标是将一段口语化的、可能充满错误的流式文本，转化为准确、通顺、符合书面规范的技术文档/对话记录。 # Critical Rules (核心处理规则) 1. **修复同音/音译错误 (Context Repair)：** - 必须根据上下文逻辑推断专业术语。 - **示例：** - `瑞艾克特` / `re act` -> `React` - `VS扣的` / `微S code` -> `VS Code` - `加瓦` -> `Java` - `APP` 被识别为 `A P P` -> `App` - `Git hub` / `给它哈布` -> `GitHub` 2. **重建标点与断句 (Punctuation Restoration)：** - 语音文本通常缺乏标点。请根据语气和语义，插入正确的全角标点（，。？！）。 - 将过长的流水账长句拆分为逻辑清晰的短句。 3. **清理口语废词 (De-filler)：** - 删除无意义的口语填充词（如：“那个”、“就是说”、“呃”、“然后呢”、“这个这个”），除非它们对语义表达至关重要。 4. **严格的中英文混排规范：** - **空格（盘古之白）：** 中文与英文/数字之间必须加空格。 - `React好用` -> `React 好用` - **大小写：** 英文专有名词必须使用官方标准大小写（如 `iOS`, `MySQL`, `jQuery`）。输出：调用一次名为 return_correction 的函数，参数： status: "ok" 或 "filtered" text: 纠正后的文本或原文 reason: 可选（若触发内容安全限制，说明原因）

1个月前

写作，不是天赋的游戏，而是积累与思考的长期修行。最近一个月，我开始认真地在 X 上发帖。短短二十多天，我输出的文字量，超过了过去三年零散输出的总和。在过往中，我学到的知识和经验，都像一堆散落的零件，直接塞进大脑的“仓库”里，从不整理，也不输出。脑子里明明装满了想法，却从未把它们转化为可见的文字。所以我每次发帖时，完全没有旧笔记可参考，也没有积累的片段可借鉴，每次都是对着某个主题从 0 开始写。现在回想，如果早几年我就开始把日常的灵感、零散的思考、有趣的观察都及时记录下来，现在我的语言表达是不是能变得更好？写作是无处安放的思绪最直接的表达方式。写的过程是在与自己对话，整理文章的过程会逼迫自己理清因果关系，挖掘深层洞见，你以为在写东西，其实是在重塑思维。所以，从这个月开始，我决定把记录当成习惯。写作，不是天赋的游戏，而是积累与思考的长期修行。

1个月前

IOS 快捷指令: 当打开 X 时自动打开小火箭，当切换到其他 APP 中是自动关闭小火箭。我录了一个视频教程，快捷指令链接放在评论区自取。

2个月前

宝玉老师说的很赞同，我可以来补充一些其他视角（后端和前端的 Vb）。在我写后端 Java 的时候，我从来不用 Vb 编程，全部手工代码，因为 Java 生态极其成熟，框架已经高度封装了底层技术细节，我只需专注于业务逻辑的实现。业务逻辑解释给 AI 的成本 > 编码成本，所以我在后端不使用 Vb 编程。但是在我写前端的时候，我往往会使用 Agent 全自动 + 一个编辑器用来微调，99% 的代码是 Agent 帮我写的，我只需要根据它的结果做一些微调，很多时候一遍过。为什么我在写前端的时候会用 Agent 全自动呢？一个很大的原因就是前端代码的重复性是无法省略的，无论你是多高级的工程师，每一个组件、每一个按钮，还是需要自己引入到合适的地方并搭配出想要的效果。每一个前端的校验、弹窗、提示、表单提交都不可能有框架替你完成，你还是要手写，这个时候 Agent 全自动的好处就凸显了，只要你把 Task 写的清楚，现在的模型能力就可以帮你进行 99% 的还原。现在前端的全栈开发，已经有成熟的 Monorepo 模式，这种模式下大模型可以在同一个仓库中了解整个项目的所有 API 和对象定义，所以我认为全栈开发使用 Monorepo + Agent 全自动，简直效率爆炸。总结一下我的想法：是否使用 Agent 全自动，取决于它是否能帮我节省时间，提高效率，而对于一个成熟的工程师来说，你应该很容易判断那些代码场景可以使用 Agent 提高效率。

2个月前

和 XiaoPeng 老师解释一下哈。 Java 的 GC 优化在业界是绝对的 T0，Go 在 GC 方面的沉淀是不如 Java 的。 Go 对于 Java 的优势在于轻量，编译成二进制包之后带来了极致的启动速度，Go 协程带来了大规模原生并发，都是优势。 Java 也知道它的这些弱势，所以 Java 通过 JIT 和 AOT 技术优化它的代码执行速度（AOT 是部分代码在打包时直接被编译为机器码，JIT 是运行时通过计算热点将热点代码直接编译为机器码并缓存）。为了实现大规模并发， Java 通过 ProjectLoom 来增添对协程的支持，并在 JDK21 中正式 GA，使得 Java 也能轻松实现大规模并发。云原生喧嚣尘上时期， Java 通过 GraalVM 增添了 Native Image 打包，打包成二进制之后，Java 应用也能被赋予极致的启动速度和极小的内存占用。再加上 T0 级别的 GC，Java 的速度比 Go 语言强一点很正常。 Tips: 榜单中同样超越 Go 的 Kotlin 语言，是和 Java 一样的 JVM 语言，两者只是编译器不同，所以 Java 的各种 JVM 优化也能同时被 Kotlin 享受到。

2个月前

使用 Gemini 3 几句话生成了一个奇门遁甲排盘程序，样式上基本不用我操心，我只需要微调一些排盘逻辑就行了～例子中使用的是奇门遁甲——时家拆补转盘排盘方式，实际效果太惊艳了～ Gemini🔗：

#Gemini #奇门遁甲 #排盘程序 #时家拆补转盘 #积极