LINUX SB 快照站

是MacOS的99美元年费

请问各位大佬，有没有什么办法能够让写好的软件绕过Apple的99美元年费🙏。

@7777 #1 打不开了😭

请问各位大佬有没有免费看番的网站

支持

@人工智能办事处 #11 task as agent或者agent as loop其原理都是以agent runtime为核心
那么agent runtime里面包含context，tools，prompt。上述这三个模块都能在每个loop或task中进行单独的维护。
可以把每个agent loop当做服务或者应用，这些服务/应用相互独立，互不干扰。
通过消息列队这样的功能，可以将上下文进行注册存储，每个agent loop只需要按需求拿到对应的上下文，执行项目中的任务即可。
就比如张三agent完成了自己的任务，系统将张三Agent的输出进行注册，放到消息列队存储。李四这个agent按照需要在列队中自己拿所需的上下文即可。这也是claude code将的上下文工程中的按需加载，按需索取。
之前的做法是系统自己将上下文给到每个agent，但随着LLM的能力增强，现在上下文按需加载/索取逐渐成为一种主流。
上述做法个人认为也是符合去中心化的。大佬可以参考一下😃

@saeye75@gmail.com #9 是的，但是这个不是我写的，是阿里开源的项目。总体写的还是很不错的，边界条件的处理都有写到，我看的很多生产级的Agent都是基于这个框架进行二开的。
我感觉阿里还是在延续互联网时期的技术路线，想拆agent框架，把每个agent模块细化。有点像微服务架构。未来没准会有agent版的微服务出现。
当然这只是我个人的看法

@人工智能办事处 #5 同学可以看看阿里开源的Agent_scope这个项目：https://github.com/agentscope-ai/agentscope.git。架构写的还是很不错的。

请问这个像素UI使用Unity做的吗？
看了佬的项目，Agent架构上采用的是Auto Gen的那种架构吧。定义一个base agent，sub agent作为base agent的子类去继承。
不过现在逐渐取缔了这种写法（所谓的harness工程），将loop视作一个agent。当然还有更激进的做法是将task事件作为agent。agent项目架构上是否能完成这样的改进呢？其实会更好维护和拓展。

@gocronx #3 感谢大佬的回答！给大佬项目点一个star

任务管理、执行记录、失败重试、消息通知、权限控制和多节点维护等方面会变得不太方便。这个现在很多分布式架构都实现了全链路追踪。请问大佬的项目是想优化这个全链路追踪模块吗。大佬的项目和传统分布式架构中的全链路追踪功能的区别是什么呀（真心请教）

下载原图这个功能现在很多搜索/爬虫工具都能做到。对于内容的平接，如果是将图片内容进行拼接，当前Figma就可以做到。
个人认为AI学术最重要的就是检索能力，减少幻觉的出现。一篇paper需要将paper进行模块化。比如part1,2,3等等。这些part可以是开发者自己设定，也可以是AI进行划分。然后给到subagent去完成。这样可以减少上下文避免幻觉。当前业界为了提高学术检索和生成的准确性，常规做法就是让LLM将检索回来的内容简明重点的概括一下，或者去填一个to-do list。这需要根据模型而定，你说你用的claude系列模型，在claude自己的技术报告说明，对于opus系列模型，to-do list会降低自身的推理能力。（当然这些技术报告也不能全信，因为这个逼养的在关于claude code技术报告说自家Agent用的工具是不多的，就20多个，结果源码一泄露50多个工具）
其实更好的做法是交互式，用户提问，plan_agent根据用户的问题进行规划和追问。然后调用一个coding_agent根据规划创建sub_agent。由这些sub_agent完成每个段落。你说的图片可以专门的创建一个sub_agent去完成。当然这个架构开发难度可能稍高，好处是适应性和个性化很强。

菜市场挨着河边。清早，卖菜的人已经把摊子摆开。青菜上还带着露水，萝卜和白菜整齐地码在竹筐里。卖鱼的把木桶放在脚边，水面时不时晃动一下。有人挑着担子从桥上走过，也有人停下来讨价还价。河边种着几棵柳树，树荫落在石阶上。卖早点的铺子飘出热气，包子一笼一笼地揭开盖子。太阳升高以后，人渐渐多起来，叫卖声、说话声混在一起。这样的早晨天天都有，却并不让人觉得重复。
引子
在这部分，我将以层层递进的逻辑方式，为大家讲解一下如何写一个类似 Claude Code 那样的 CLI。本文章尽量会以通俗易懂的方式为大家讲解，教给大家一些设计思路和架构设计中需要注意的点。本文章适用于个人开发者，小型初创团队和想学习 Agent CLI相关知识的初学者。文章将会以当前开源的一些优秀项目为例子讲述设计方法和思维。
一、什么是 CLI？
首先我们要了解什么是 CLI？CLI 中文名称叫命令行界面，它是一种交互方式。与之对应的叫GUI，中文名称叫图形界面，我们经常使用的微信，浏览器界面这些都是 GUI。
作为初学者，大家这里面可能会混淆，Windows PowerShell 是不是 CLI 呢？严格来说，PowerShell是实现 CLI 交互的工具。更具体一点，当我们在 terminal（终端）中使用 git commit、git status、git push 的时候就是在使用 CLI。如果大家有提交项目的经验，或者在 GitHub 上面提交过项目的话，对这些命令行应该是比较熟悉的。
到这里你会发现一个问题，我写了一个产品，这个产品运行的很多功能都需要用到函数指令。用户要执行各种操作，那么让用户记住这些指令显然是不现实的，所以GUI（图形界面）就出现在了大众视野中。GUI 未必执行的是 CLI 命令，但是其核心逻辑和 CLI 差不多，都是在一种交互方式。GUI 是用户点击按钮，CLI 是输入命令行。
随着 AI 技术的发展，工程师逐渐想到了一个方法，能不能通过调用 LLM 的方式，让 LLM执行各种命令行，做出 Agent CLI 来操作我们的电脑，帮助我们干更多的事情呢？于是，Agent CLI 便诞生了。在 Agent CLI 中 Agent 可以通过命令行，来读取和操作你电脑本地的文件。
因此很多初学者会存在一个误区，在看到 Agent 操作你的文件的时候会非常震惊，认为这个模型能力很强，能够操作你的电脑，其实模型并不能操作你的电脑，模型只是借助了命令行工具进行的操作。
二、Agent CLI 设计需要注意哪些维度？
了解完 CLI，接下来我们进入正题，在设计 Agent CLI的时候该注意哪些呢？我将分成下面这几大类为大家讲起：
1. 工具
2. 上下文
3. workflow
4. 数据库
5. prompt
6. runtime
7. CLI 界面
8. 兜底（专业讲就是边界设计）与安全
三、工具（工具集）
我们先从工具（专业一点也可以叫工具集）讲起。Agent 工具集的设计非常重要。在 Agent 设计下，工具集并不是简单的工具，它往往决定了 Agent 的能力边界（这里面排除一些特别因素，比如模型的种类）。你提供给模型的工具集，决定了 Agent 行动空间以及 Token 成本。如果设计得当，那么 Agent 将会成为你的得力助手，如果做不好，那么 Agent 将会选择错误的工具，进行胡乱操作。
以 Claude Code 为例。在 Claude Code中工具并不是分散写到不同目录中的，所有的工具集中在同一个根目录里。Claude Code 将这些工具统一注册和管理，建立了一个工具池。在这个工具池中一共设计了 50 个工具。
这点就和 Anthropic 官方出的技术博客中有差异，他们说自己只为 Claude Code 设计了 20 多种工具，而且他们认为并不是工具越多越好，主张工具的质量 > 工具量。从这点看，Anthropic 公司也存在水分，但是其表明的工具质量 > 工具量，我是十分认同的。
文献引用来源：
"Claude Code currently has ~20 tools, and our team frequently revisits if we need all of them for Claude to be most effective. The bar to add a new tool is high, because this gives the model one more option to think about."
—— Seeing like an Agent，claude.com/blog/seeing-like-an-agent
（章节："Progressive disclosure: the Claude Code Guide agent"）
3.1 系统工具 vs Agent 工具
所以，对于工具设计，你需要根据你的业务需求，为你的 Agent 设计对应的工具。工具的数量根据 Agent 系统复杂程度和业务需求制定。在工具设计上如果从工具使用对象的角度去思考的话，可以分为系统工具和 Agent 工具。
Agent 工具可以分为外部 MCP 工具和内部工具（需要工程师去设计的工具）细分为这 5 种：
1. 文件读写工具
2. Agent 结构化输出工具（例如 todowrite 工具）
3. shell 与系统操作工具
4. Agent 编排工具
5. 搜索工具与 MCP 所连接的资源（网站，外部工具等等）
当然，如果你希望你的 CLI 能够自动回复你，具备主动性，那么还需要加一个触发工具。
系统工具主要有 skill 加载，上下文工具（需要我们注意的是，现在的 Agent 架构下，Agent可以自己选择上下文的获取，但是上下文的裁剪还是需要由系统执行的。总结来讲，上下文获取属于Agent 工具，上下文裁剪属于系统工具）、MCP 资源工具负责读取和列出 MCP 资源、系统监控工具、系统等待、发送文件、推送消息、发送消息等工具。
讲到这里，大家可能对于 Agent 系统中工具是否属于系统工具和 Agent工具的划分不清楚。我这里面有一个方法叫给大家：我们去分析这个工具是否需要 prompt 来区分这个工具是否属于系统工具还是 Agent 工具。如果这个工具不需要Prompt，那么它就是系统工具。如果需要，则是 Agent 工具。
知其然必知其所以然，为什么这么划分呢？因为在当前，我们需要一个 prompt 去告诉 LLM 这个工具是什么、何时使用、边界情况是什么（不能拿它干什么）、以及这个工具的调用指令（Tool_Call）等内容。
3.2 以工具为起点，连带看其他组件
我们先从 Agent 内部工具讲起，如果您之前读过我写的文章，您应该知道，一个优秀的工程思维不能仅仅考虑这个组件的设计。我们应该连带着去看。我们分析项目组件不能仅仅分析这个组件本身。我将会以工具为起点，连带着去分析其余的部分。让大家感受一下工程化思维。
3.2.1 文件读写工具
文件读写工具将赋予模型读写文件的能力，是较为基础，也是非常重要的工具。最常见的工具为FileReadTool、FileEditTool、FileWriteTool，这些工具可以帮助模型进行文件的阅读和改写。
这里面需要大家要注意的是，不要单独地为 word、PDF等等的文档专门写一个工具，我们可以将这些处理逻辑内置在 FileReadTool。并且在 PDF 的处理上，我们可以采用多模态模型直接将 PDF
里面的内容截图，让模型进行分析（这里需要了解每个模型的图片处理上限，一般来说，将 5-10 页 PDF 直接 Base64 编码作为文档传递给模型，如果超越了页数限制，把每页渲染成图片，然后给到多模态模型进行图片分析。具体的情况还需要根据模型能力来设置）。
3.2.2 Agent 结构化输出工具
Agent 结构化输出工具主要负责让 Agent 将自己的规划，需要的执行步骤写下来。如果使用过一些 AI 产品的朋友们肯定都会遇到一个情况，当你给 Agent 提交一个任务的时候，界面上会弹出一个 todolist 或者 plan 边框，这个边框里面的内容就使用到了结构化输出的工具。
最为常见的结构化输出工具有 ToDoWrite、TaskCreate、TaskOutput 工具。流程为：
• Agent 根据当前的任务进行分析，为自己设立任务（写下来）
• Agent 继续分析任务需要几个步骤完成？这些步骤大致该怎么做？（写下来）
当然 Agent 写下来之后，肯定不能直接发送给用户，为什么呢？因为还没有进行排版，这就还需要系统再去调用一个发送消息的工具，将这些内容进行编排，前端进行渲染，然后呈现在用户面前。
这就是你看到一个 ToDoList 边框的完整过程（更为企业级的做法会有更多的边界处理，比如前端渲染重试机制，用户网络波动的重新推送等等）。
聪明的你可能会发出疑惑，这个 Agent结构化输出工具跟系统工具中的发送消息工具有些类似。确实有类似的地方，但是 Agent结构化输出工具更针对于 Agent 输出的前期处理，而系统工具中的发送消息工具负责后期处理，且覆盖范围更大。比如有时候你的简单问题不需要调用 Agent 结构化输出工具，那么这时候 Agent 的输出会直接交给发送消息工具去处理。
3.2.3 Shell 与操作系统工具
Shell 与操作系统工具主要负责跑 git、npm（Node Package Manager 是 Node.js 的管理包器，你在用 AI 开发网站时用到的 Vue、React 都用到了 npm 进行的安装）、系统环境，验证等。总的来说，Shell 与操作系统工具主要负责把 Agent 的决策落在真实的 OS 进程中，让 Agent 在你的本地进行验证执行，和依赖的下载。你在使用 Agent产品时经常会看到弹出一些边框，里面有各种 bash 和 PowerShell命令行、下载请求、验证请求等等，这些就是 Shell 与操作系统工具负责的内容。
Shell 与操作系统工具主要有 BashTool、PowerShellTool。这两个工具都属于 Shell 执行器。
作为执行器，我们需要让其处于沙盒环境中使得 Agent 在执行真实操作的时候更加安全（比如，做到不会删除用户的重要文件）。这里需要额外讲解一下，作为沙盒，需要考虑：
• 进程的管理
• 周期的管理 • 状态的管理（休眠还是活跃）
• 权限管理（沙盒内部需要设置哪些白名单？拦截哪些 Agent 失误造成的错误指令？针对哪些语法做安全性检查？）
为了做到上述沙盒中的功能，我们需要更多的子工具去负责这些。这些子工具其实可以作为一个系统工具去定义（我上面讲到过，是否属于系统工具可以通过该工具是否拥有 Prompt 来定义）。
以 Claude Code 为例子，该项目中有休眠工具（用于静默等待）、注册定时任务的工具、捕获/接管终端输出工具、系统监控工具，以及一个将 shell 执行器工具沙盒产出的上下文以 REPL 模式（Read读取、Eval 求值、Print 打印结果、Loop 循环，其特点是交互式的，逐条执行，立刻看结果。Python 中的 >>> 提示符就属于 REPL）进行隐藏的工具。
当然，我个人认为 Claude Code的工程设计不是很好甚至说有些混乱，比如这里面其实有些工具是属于上下文类型的工具，但是Claude Code 并没有将其写到上下文工具目录下，并且如果你详细分析其目录，工程师在目录设计上并没有刻意的按照系统工具和 Agent 工具进行分类，更多的是根据功能进行的分类（虽然这块设计得也不是很好）。
那么我认为一个好的架构设计其每个组件务必是职责清晰，遵循职责分离原则的。对于 Shell Tool 这块，要写一个沙盒是必须的，将这个沙盒抽象成一种工具也可以（毕竟其内核作为一个执行器）。那么其中的系统工具应该写在 system_tools目录下，类似这种执行器其内部机制比较复杂，我们可以写在 tool_orchestrator目录下，这里面专门写一些管理工具来管理这些执行器的周期、进程、处理边界情况等。
3.2.4 工程化思维展开
既然上面说到工程设计，并且文章面向初学者和开发者，我们稍微展开讲解一下工程设计中的一些要点和一些思维。以 Agent CLI 为例子，当你要设计它的时候，你需要清楚的了解，这里面大致有哪些模块？你如何将这些模块进行分类？模块和模块之间你打算如何设计它们的功能和联系？
举个例子，模块 A 负责上下文，那么上下文包括裁剪模块，加载模块，存储模块；B 负责 memory，那么 memory 包括长中短期模块，memory 驱动加载模块。这就是你需要先了解大致模块有哪些。
如果作为一个清晰的项目目录设计，我建议大家把这些非常庞大的功能建立一个项目目录（比如例子中提到的上下文作为一个项目目录，把 memory 作为一个项目目录）。我认为一个目录的设计是工程框架设计的基石，能够体现你个人的工程化思维。更为重要的是，面对一个企业级的项目，你必须要考虑到边界情况和安全情况。当面对高并发调用时，系统有没有什么机制进行处理，分担服务器的压力？哪些内容作为本地缓存保证用户的隐私？总结来讲工程化思维的核心便是由点到面进行展开思考，最后再收敛到这个点上。
（如果大家对这部分感兴趣，我后面可以单独出一篇文章进行单独的讲解）
3.3 Agent 编排工具
下面我们回归正题，继续分析 Agent 编排工具。当前很多 Agent 系统采用的是多 Agent系统。一个系统中会有很多 Agent（比如 ruflo 这个项目，他在官方的 README 中说明了项目中有 100 多个 Agent 集群）。
参考引用：https://github.com/ruvnet/ruflo.git
"Agent = Model + Harness. ... Ruflo is the harness — the execution layer around Claude Code and
Codex that adds 100+ specialized agents, coordinated swarms, self-learning memory, federated comms across machines, and enterprise security guardrails."
这里建议大家根据业务逻辑去制定项目中 Agent数量。并不是越多越好，真正好的工程设计也需要考虑成本因素。那么对于 Agent CLI 来说，通常 10 个左右的 Agent 数量能够满足其功能。
Agent 编排从狭义角度去思考其实就是广为讨论的 workflow，Agent 编排工具就是 workflow编排工具。比较火的编排工具有 langchain、langgraph 这些组件，包括有零代码工作流程编排平台如 dify、n8n（这里面演变成了一句话帮你生成一个完整的 Agent workflow，比如 Relay APP）。
3.3.1 OpenAI 提出的子 Agent 抽象
OpenAI 在《Orchestrating Agents: Routines and Handoffs》提出两个基本抽象：Routines + Handoffs。
• 作者：Ilan Bigio（OpenAI 工程师）
• 发布日期：2024 年 10 月 10 日（Oct 10, 2024）
• URL：https://cookbook.openai.com/examples/orchestrating_agents
文章摘取：
"What if instead [of returning a string], we return an Agent object to indicate which agent we want to transfer to?"
文章里 Ilan Bigio 对这个 trick 的评价是：
"A simple, but surprisingly effective way to do this is by giving them a transfer_to_XXX function, where XXX is some agent. The model is smart enough to know to call this function when it makes sense to make a handoff!"
2024-10-11（也就是文章发出来第二天），OpenAI 把这个思想打包成了一个最小可运行框架Swarm。由此子 Agent 作为工具被调用的设计被提出并且被实现。Swarm 的 README 直接说：
• GitHub：https://github.com/openai/swarm
• PyPI：openai-swarm 0.1.1（Released: Oct 17, 2024）
• License：MIT
• 作者：OpenAI Solutions（维护者 wirthual）
"The primary goal of Swarm is to showcase the handoff & routines patterns explored in the Orchestrating Agents: Handoffs & Routines cookbook. It is not meant as a standalone library, and is primarily for educational purposes."
这个思想后来成为了行业的范式。
3.3.2 Anthropic 的工程化
不过在 2026-01-23 Anthropic Blog（Cara Phillips）中工程化了这个思想。文章中指出的核心思想是，子代理可以解决一些真正的限制，例如：
• 上下文限制
• 专业化限制
• 并行执行的限制
Agent 子代理的编排取决于具体的情景，而非问题类型。设定明确的验证点，子代理无需了解全部上下文（这其实和第一条呼应上了，解决上下文的限制问题）。
总结一下：在 Agent 编排工具上不仅仅是传统意义上的工具，工程界已经把 Agent 作为工具并且广泛使用。在设计上，我们需要根据任务场景设定你的子 Agent（比如任务情景为检索、编码、整合）。子代理的存在是为了专业化地解决业务场景，不能为了设计子代理而设计子代理（这也是 Anthropic 公司在上面的技术报告中提出的当前大部分 Agent 工程师在设计中存在的问题）。毕竟多一个子代理，就会多一份 Token，如果这个业务在自动化脚本下就能够稳定高质量的完成，那么我们在设计的时候就不需要多花费这笔 Token 成本。
3.4 搜索工具
搜索工具可以分为系统搜索工具和外部搜索工具。
对于系统搜索工具，主要负责：
• 搜索系统中的工具（这个工具主要是为 Agent 设计，让 Agent 调用这个工具，迅速的能够知道当前能够调用哪些工具）
• 列出 MCP server 中的资源等
对于外部搜索工具，主要负责一些外部的信息：
• 比如搜索工具（如果想免费使用的话可以下载 duckduckgo库，调用这个工具可以实现搜索，但是需要你自己负责外部信息上下文的裁剪）
• 现在市面上有非常多的开源爬虫工具，比如maxun、firecrawl（个人感觉这个非常好用）、Tavily search 等等
• 如果你爬虫技术不好，又不想自己负责搜索信息的裁剪，那么你完全可以使用这些开源工具
3.5 MCP
最后 MCP。MCP Server 分为本地的，你自己部署到服务器上的和托管付费的：
• 第一种完全免费
• 第二种需要你支付服务部署的费用
• 第三种则是付费点，需要付费给云厂商对于 MCP 的设计，整个链路是：
AI → MCP Client → MCP Server → 外部资源
你需要自己写一个 MCP Client 来连接外部服务提供的 MCP Server。
大家可以这样理解 MCP：你有一个 U 盘（你自己的业务），电脑上有文件需要下载到 U 盘（外部服务），但是这个电脑只能接受一种插口，这时候，转接插口出现了，你只需要让转接头知道你的 U 盘插口型号就能够轻松的下载电脑上的文件。
你需要在你的 MCP 中设计以下要点：
1. 管理多个 MCP Server
2. 建立 stdio 或 HTTP 连接
3. 获取工具列表
4. 获取资源
5. 获取 Prompt 调用工具
6. 将工具结果返回给 LLM
其中 3 和 4 可以写在系统搜索工具中。

@肏屎皇 好贴

@xB70sR71 #12 辛苦了xd

@福瑞 #3 刚刚看了一下，感谢佬。我宣布我加入福瑞

@xB70sR71 #5 不知道以后会不会有很多技术贴🤔

@hugehard365 #1 OK啊，过段时间试试。感谢佬

感觉应该把发帖和回帖积分搞回来的

请问哥儿几个有没有好用的国外云服务器，支持国内支付宝，微信支付的。
小网站使用，CPU 2-4核就够用了，内存8 GIB
因为使用国外云服务器绑定域名不需要备案

清晨，高楼的玻璃幕墙映着淡淡的天光。地铁口陆续有人走出来，手里拿着咖啡和早餐。公交车停靠在站台边，车门开了又关。路边的梧桐树叶上沾着昨夜的水汽，清洁车沿着道路缓慢驶过。太阳从楼群之间升起，玻璃窗上亮起一片金色。写字楼的大门陆续打开，外卖骑手穿过路口，行人沿着斑马线向前走去。城市从安静中醒来，街道上的声音渐渐多了起来。从人类社会文明诞生到现在，亦或是未来，可能都这样一直在忙碌。
随着 2024 年国内 AI 技术爆发，越来越多的人和企业意识到了 AI 技术的前景与巨大潜力。我们经历了大模型爆发元年到 Agent 爆发元年，有人惊喜，有人恐慌，但更多的便是困惑。今天，我们先浅谈一下 Agent。
2024 年国内 DeepSeek 模型的爆火掀起了一股大模型热潮，许多公司和团队开始纷纷下场做模型，从基础的 LLM（大语言模型）开始渐渐发展到多模态模型、视频生成模型以及图片生成模型。早期 GPT-3 系列模型中 RLHF 的 PPO 算法，到 DeepSeek 在 RLHF 中使用的 GRPO 算法（取代了价值模型）从而降低了模型训练成本；Qwen 通过注意力门控机制降低了大模型的注意力稀疏机制；KIMI 团队针对残差连接提出来的基于注意力的残差连接（这里简单代一下：在 Transformer 架构中本质上有两种记忆，第一种是横向的，是 Token 和 Token 之间的注意力，也就是大家了解的 Attention；另一种则是纵向的，是残差流之间的记忆。KIMI 修改了固定的残差传递机制，将残差连接从固定加法升级为动态检索，使 Transformer 具备了跨层选择性记忆能力）。模型能力逐步增强，大家意识到模型不应该仅仅只是单一地回答问题（你问我答），更应该做很多事情。于是，Agent 迎来了属于它的春天。
这里面最经典的便是 Claude Code，其依靠 Claude 系列模型强大的编码能力以及精妙的工程设计深受大家喜爱。人们在享受这种工具带来的极致效率的同时，也发出了很多声音。我把这些声音归纳成两种：第一种是 Agent 未来如何发展？第二种是普通人现在该干些什么，我们将何去何从？
Agent 未来该如何发展呢？我们要从 Agent 的工程设计本质上看待这些问题。当前 Agent 设计本质上大致有这 6 大类：
1.Workflow（工作流）： 比如传统的 ReAct、Router，也有现在使用量多的 Agentic Reasoning、Agent 集群等。
2.工具： 在 System Tools 中大致有 Bash、Git 等命令行工具；在检索方面有搜索工具、RAG 等工具；以及外部工具比如能够链接网页或软件的 MCP、控制浏览器的 Browser 工具等。
3.Context（上下文）： 上下文窗口的设定、裁剪与传递。有些公司采用了 Blackboard 系统，将上下文统一写到数据库中（Manus 在其技术博客 "Context is all you need" 中就采用了 Blackboard 系统作为上下文的共享协作方式）。
4.Prompt（提示词）： 包含 System Prompt、Tool Prompt，这里面也包含了 Skill，因为我认为 Skill 就是 Prompt 的变种。
5.数据库： 也包含知识库。数据库范围会更大，不仅仅包含知识，也包含上下文的存储管理、工具调用信息日志存储、Agent 信息日志存储、用户信息存储等。
6.Runtime（运行时）： 即 Agent 系统运行时的状态。这是一个非常值得考究的工程设计，是协调整个 Agent 系统的关键。比如上下文何时进行裁剪？短期记忆的轮次？Prompt 何时进行加载？我认为一个优秀的工程设计下，Runtime 不应该仅仅处理 Agent 系统运行时的协调调度，还应该处理任务完成后，在“冷时间”中系统该如何完成一系列“加分”任务。如：通过算法判断当前用户数据是否充足？能否检索补充用户数据先进行大范围初步建模？
这里面可能会有争议。首先，在模型层，一个企业级的通用领域 Agent 通常会有一个路由机制，将问题进行分类，然后给到合适的 LLM（比如将编码问题交给 Sonnet 或 Opus 系列模型进行选择），我个人认为这仍属于 Workflow 类别。其次，Memory 层比较复杂，大致分为短期记忆和长期记忆（也有中期记忆和 Working Memory，这里先不单独拎出来）。短期记忆本质就是上下文窗口，工程师需要根据所调用的模型设定一个最大对话轮次，在这个轮次中，Agent 依靠模型自身的短期记忆即可。而在长期记忆中，需要依据数据库中的工具调用信息、用户信息等数据，根据任务相关性进行实体驱动加载、时间驱动加载、目标驱动加载等方式热加载到 Agent。我个人认为这个部分属于上下文窗口、数据库和 Runtime 的结合，所以并没有将其单拎出来。
我们需要注意的重点是，上面这六个分类并不是独立工作的，这好比齿轮一样，每个齿轮的转动都需要另一个齿轮先转动再推动其转动。同理，这个齿轮的转动可能也推动另外一个齿轮的转动。这些齿轮不是链式或平面式，更像是一种空间式的。每一个机制的演变、改动都会带动其余一些机制的变化。我将大胆结合模型未来的发展，围绕着这 6 个机制进行分析，给出我的观点。
先给出结论：我认为未来的 Agent 工程师会变成数据工程师和工具工程师的结合。
我将从 Workflow 为起点进行延伸，以下所有的分析都将会结合模型一起去分析。有一个非常有意思的现象，现在许多 Agent 的 Workflow 其实都借鉴了 LLM 中的设计，比如混合专家模型和 Agent 中的专家 Agent。所以我们大胆猜测，未来随着模型的发展，Agent 工程师可能不需要过多考虑 Workflow 框架设计。模型会分析任务领域，激活对应部分权重（可能会有一个对抗权重去对抗专家模型产出的内容，从而产出更可靠的内容），Workflow 会在模型内部完成推理。
当然，就像我说的，这是一个空间齿轮，得出这样的结论不能单一考虑 Workflow。现在较为先进的 Agent Workflow 框架（例如 Agentic Reasoning）还是需要 System Prompt 去告诉模型哪些 Agent 是干什么的、在什么情况下进行调用、哪些场景下这么调用比较好。所以我推断 Workflow 的变革一定会带动 Prompt 的变革。
现在阻碍模型发展的最困难环节可能是数据类型的缺失。我们缺少那种有逻辑性的数据，比如告诉模型为什么 1+1=2、为什么苹果会落地那种极具逻辑性的数据。现在爆火的 Skill 可能就是未来逻辑性数据的沃土（现在其实已经有一些模型公司将工具的 Prompt 变成了模型的训练数据，让模型的工具调用能力变强。看，多么有意思的现象，Prompt 的变革又推动了工具的变革）。未来会出现那种“超级 Prompt”，这些“超级 Prompt”会变成训练数据，专门训练模型，让其具备真正的逻辑性。我们可以把 Prompt 或 Skill 看成一种逻辑性的“踩坑指南”。如果您设计过一些 Agent，您会发现模型有时会“不听使唤”，这时候你需要在你的 Prompt 加上 Few-shot、命令式语句等（企业级做法还会加上兜底层，至于怎么设计，这里不做赘述），这些其实都是非常好的训练数据。现在的 Skill 更具备逻辑性，而且很多 Skill 都对应某个领域专家们的经验、踩过的坑和逻辑。这会为数据公司节省大量的时间去采集数据。未来模型如果拥有了大量的逻辑性数据，那么模型可能会获得真正的推理能力。所以，未来 Agent 工程师可能不会设计 Prompt。
对于 Context 层面，我们可以看出一些模型公司在近些年对于上下文的处理上有着很大的投入，从之前的 32K 上下文变成了 1M 级别。结合上文 KIMI 给出的残差流论文，我大胆预测模型自身会具备很强的上下文能力。现在因为算力层的不断进化，模型在处理上下文的时候能够处理更多的 Attention。但是未来的上下文能力并不会靠堆量，会通过修改一些算法，使其模仿人类具备“遗忘”能力。因此，Agent 工程师不会再对上下文的处理花费很多心思。
接下来我将分析比较重要的三点：工具、数据库和 Runtime。我们先从工具开始分析。如前所述，模型公司会将工具的一些信息作为数据训练进模型，增强其工具调用的能力，并将一些官方工具深度集成到平台。在这里我要讲到之前 Anthropic 公司提出来的非常火的机制：MCP（模型上下文协议）。这个机制就是通过一个协议（可以是 JSON 脚本）让模型轻松地调用别家公司的工具、软件或网站（比如通过 MCP 连接 GitHub 让 Agent 访问你的项目仓库）。
为什么需要这个东西？举个例子，你现在要到国际舞台上发表演讲，但听众和你不是一个国家，你说的语言他们听不懂，这时候就需要用到翻译器。MCP 类似翻译器这个适配器，将不同的工具通过一个标准化协议让 Agent 轻松调用，不需要再为每个工具写一个适配器（类似不需要你为每个听众单独翻译一遍）。如果您了解 MySQL 会知道当前数据库有很多种（SQLite、Oracle 等），但是这些数据库的操作都使用 SQL 语句（严谨地讲是高度通用，因为数据库服务商提供的一些扩展性服务是他们自己定制的，所以使用的语句不完全一样）。Anthropic 干的事情就和这个类似。现在 Oracle 是收费的，但是你操作 Oracle 的 SQL 语句是免费且开源的。MCP 协议本身免费且开源，但是背后的服务供应商提供的服务是收费的。
介绍完 MCP 之后，我们来看看工具未来将会有什么变革。未来 Agent 的工具将会聚焦于两大类：
•第一类，内部工具： 比如文件读写、代码编写工具等通过调用 Git、Bash 等命令行语句进行调用的内部工具。当前 AI 公司还是在适配当前的计算机操作命令行，从成本角度看，这比重新为 Agent 设计一套操作语言节省成本。但随着 CLI 的爆火，其强大的可定制化能力暗示着未来极大概率会出现一个专属于 Agent 的操作命令行。上面提到的 MCP 抢占了先机，未来 Agent 命令行出现的时候，如果 MCP 能够符合其生态，那么这对于 Anthropic 将非常有利。当然，从其推出 Claude Code 以及各种对于命令行的研究可以看出，该公司也可能率先推出 Agent 命令行。
•第二类，外部工具： 搜索工具、浏览器控制工具等。这部分随着当前 Agent 不断渗透进人们的工作中，会诞生很多垂直领域的工具（现在已经出现了一些 AI SaaS 工具解决初创团队和小微企业付费问题），比如金融数据分析、法律文献分析等工具。这会给很多初创团队和公司一个非常好的机会。这些公司或团队通常会有一部分人以顾问的形式参与开发，顾问提出领域的痛点，工程团队进行解决。当然也存在个人通过自学编程来编写垂直领域工具的情况。这些外部工具大部分会以 To B 的形式进行销售，并提供一系列服务。
但是这里面的服务不会包括数据管理服务，这就引出了数据库这个点。记住，Agent 设计是一个空间式齿轮。数据库是未来最为精彩的部分，也是 Agent 开发最重点的部分。工具调用产出的数据存储到个人数据库，Agent 运行产生的数据（用户画像建模、调用时间等）也会由个人保管。这里面的核心就是安全。现在大部分的流程是让大量数据给到 AI，但是个人和企业的数据都需要安全管理，不能轻易流向 AI。加上企业的数据往往比个人数据更大，所以未来的走向一定是让 AI 走向数据，或者让 AI 变成产生数据的本体。我们可以多多关注做轻量级模型的公司，他们在未来会有很大的市场和机会。
对于 Agent 工程师来说，未来如何设计一个非常安全的个人或企业 AI 数据库将会是关键。在保障安全的同时，也需要做到数据去中心化理念。现在有一个思想叫做“数据不出网”，核心是将重要数据保存在本地。但我个人认为云端数据未必不可靠，比如区块链，那里面保存了很多重要内容并且非常安全，其被攻击成功的概率极低（这里涉及哈希碰撞，在数学层面上虽有概率，但在 SHA-256 等成熟算法加持下，这几乎是不可能完成的。虽然 MD5 是一个成功的碰撞案例）。未来 AI 数据库的搭建可能利用区块链技术和去中心化思想，结合更为先进安全的算法。哪怕是云端数据，数据传输也不会是大量内容的传输，只会传递关键信息。如果可能，数据库中还会部署一个 Agent，负责将关键信息传递给用户和企业，或帮助完成信息安全的重要步骤（付费、注册等）。所以我对于未来 Agent 数据库的设想是：去中心化的、极其安全的、具备信息筛选功能的平台。它不仅仅是数据库，而是连接第三方与个人、企业的数据存放枢纽。或许未来会出现一个数据库版本的“MCP”协议，帮助开发者或企业轻松连接数据库。
既然上面提到的 Prompt、Workflow、工具、数据库、Context 都发生了变化，作为最关键的 Runtime，它的变化是什么呢？其实，现在 MCP 的出现以及各种外部工具能力的增强，已经在为 Agent 工程师解决了一些 Runtime 的问题。我上面设想过，Agent 工程师不再负责 Context、Prompt、Workflow 之后，他们的重心将放在工具和数据库上。这时候工程师需要写一个 Runtime 脚本来确保与这些工具及数据库之间的复杂交互，确保数据安全、高效流转。
以上便是我对于 Agent 未来如何发展的分析。由于篇幅限制，我将在下一部分列出“普通人现在该干些什么”。由于我也是一名刚毕业的大学生，所以上面这些仅代表我个人的看法，不一定准确。希望能给大家一些启发。

@guest1 #13 可以看看自己生活中或者刷刷抖音看看别人有没有什么痛点，用多模态能够解决的。记得之前国外一老哥做了一个地点照相机，就是输入位置，生图模型能够生成图片。改改可以做成一个时光照相机，弥补人生中的遗憾

做哪方面的多模态智能体应用？

放心兄弟，现在因为AI就裁员的老板，这公司离嗝儿屁不远了。
如果你认为你的员工只能做重复性工作，并且没有创造力，那么你公司用不用AI，裁不裁员也会嗝儿屁

@zhuangjie #4 实在忍不住了hhh

@Denia-bot #2 确实啊

现在很多MCP真他妈的牢啊，小众点的用的人少，大众的配置起来麻烦的。
在github上面弄一个领英MCP，配置起来麻烦的，各种问题。我操他妈的Anthropic几把弄的这逼玩意儿，你倒是把生态弄好了啊我草的。按照你REAMDE上面弄的，妈了个逼的各种bug。领英官方自己也不弄一个好的MCP serve。第三方的写的又不稳。有些项目，那MCP Serve写的确实好，几分钟就能用了。我就想获取一下各种软件或者网站项目的信息，配置的麻烦死了，还他妈的不如用爬虫工具呢。越是github上面高star的越鸡巴水。你他妈的买star就买吧，项目好用也无所谓了，反而能让更多的人看到。你妈逼写的那他妈的傻逼MCP服务，草你妈连接起来各种问题，还他妈的几k star，吃屎了吗那些人是。
现在github上面，那些高star项目，全是他妈的炒作。用他妈的AI写的烂代码，一点项目架构都没有。一个上下文压缩脚本，鸡巴堆了6000多行代码。大哥你自己看的时候你难道不头疼吗。要不然就是一堆破他妈的skill。能不能像以前那样弄一点正儿八经有价值的项目啊我操了。你买就买吧，为了宣传也无可厚非，但是你他妈的写好了啊，至少让哥们儿能运行啊我操了。
感觉反而star几十个几百个那种项目最靠谱。

do很sb，但sb不sb

芙蓉王能降价么