1. 这条新闻到底在说什么：三件事拆开看

2026年9月30日这条AI新闻，信息密度相当高，三条主线各自独立又互相咬合。我把它拆成三个关键词：GPT-6.1 Sol降价、Dots常驻Agent、AMD收购World Labs。这三件事分别对应大模型推理成本、Agent产品形态、芯片厂商的AI战略布局，放在同一天出现，基本能看出接下来一年行业的风向。

先说GPT-6.1 Sol。Sol是OpenAI在这一代模型里推出的一个推理优化版本，主打的是“同等能力、极低单价”。这次价格直接降到原来的五分之一，意味着原本跑一次要花5块钱的任务，现在1块钱就能跑完。对做Agent开发、批量内容生成、自动化工作流的人来说，这是实打实的成本重构。我身边做AI应用的朋友，第一反应都是“终于可以把之前因为成本砍掉的功能加回来了”。

再说Dots常驻Agent。Dots是一个Agent产品，这次的核心变化是“常驻”——它不再是你打开网页、输入问题、等回答、关掉页面这种一次性交互，而是像一个后台服务一样持续运行，有自己的记忆、有自己的任务队列、能在你不在的时候继续干活。这个形态变化比模型降价更值得关注，因为它改变了人和AI的协作方式：从“我问你答”变成“你盯着，有事叫我”。

最后是AMD收购World Labs。World Labs是做空间智能和3D世界生成的团队，AMD把它收进来，意图很明显：在AI训练和推理的芯片战场上，不能只拼算力数字，还要拼“能跑什么”。英伟达有CUDA生态，AMD想用“能跑空间智能、能跑世界模型”来差异化。这笔收购对开发者的直接影响是：未来AMD显卡在AI工作流里的角色可能会变，不再只是“便宜替代品”，而是“某些场景下的唯一选择”。

这三件事放在一起看，其实是一条线：模型变便宜了，Agent可以常驻了，跑Agent的硬件也在重新洗牌。下面我按这个逻辑，把每一块拆开讲透。

2. GPT-6.1 Sol降价五分之四：成本账怎么算，什么场景最受益

2.1 降价背后的技术逻辑：不是亏本卖，是推理效率真的上来了

很多人看到“降到五分之一”第一反应是“烧钱抢市场”。我一开始也这么想，但仔细看Sol这个版本的技术路线，降价是有支撑的。Sol的核心优化方向是推理时的计算复用和稀疏激活。简单说，以前模型回答一个问题，要把所有参数都过一遍；现在Sol只激活跟当前问题最相关的那部分参数，其余部分休眠。这就像你家里有100个灯泡，以前开灯全亮，现在只亮你所在房间的那几盏。

另一个关键是KV Cache的压缩和复用。Agent场景下，很多请求是连续的、有上下文依赖的。Sol把之前对话的缓存压缩后保留，新请求来了直接复用，不用从头算。这个优化对常驻Agent尤其重要，因为Agent本来就是长时间运行、反复调用模型的。

注意：降价不等于能力下降。Sol在标准基准测试上的得分和上一代持平，但在长上下文和连续对话场景下，因为缓存复用，响应速度反而更快。如果你之前因为成本问题把上下文窗口调得很小，现在可以适当放宽了。

2.2 成本对比：一张表看清降了多少

我拿几个典型场景做了估算，按Sol降价前后的单价对比：

这张表里最值得看的是最后一行。常驻Agent以前最大的成本障碍就是“它一直在跑，token一直在烧”。降价后，一个常驻Agent日运行成本从10块降到2块，一个月60块，这个数字对个人开发者和小团队来说完全可以接受。

2.3 什么场景最该立刻用起来

降价之后，有几类场景的ROI变化最明显：

• 批量内容处理：比如把1000篇长文摘要成短讯，以前要40块，现在8块。如果你在做内容聚合、舆情监控、知识库构建，这个成本下降直接让项目从“不划算”变成“可以跑”。
• Agent任务链：Agent执行一个复杂任务往往要调用模型几十次，每次都要带上下文。以前跑一个任务链要一块多，现在三毛。这意味着你可以让Agent做更长的推理链、更多的自我检查步骤，而不担心成本爆炸。
• 常驻型个人助理：Dots这类常驻Agent，以前大家不敢让它一直开着，现在可以了。你让它盯着你的邮件、监控某个数据源、定时整理信息，一个月几十块的成本，比请人便宜太多。
• 教育和小规模实验：学生、独立研究者以前做实验要精打细算token，现在可以放开跑。这对AI教育的普及是好事。

实操心得：降价后不要立刻把所有任务的模型都换成Sol。有些任务对推理深度要求高，Sol的稀疏激活可能在某些复杂逻辑题上表现不如全量模型。我的做法是：批量、重复、上下文连续的任务用Sol；单次、高复杂度、需要深度推理的任务保留原模型。混合使用，成本降了，质量不降。

2.4 怎么在代码里切换和验证

如果你用的是OpenAI兼容的API，切换模型通常只需要改一个参数。以Python为例：

from openai import OpenAI client = OpenAI( api_key="你的key", base_url="你的接口地址" ) # 以前用的模型 # response = client.chat.completions.create(model="gpt-6.0", ...) # 切换到Sol response = client.chat.completions.create( model="gpt-6.1-sol", messages=[ {"role": "system", "content": "你是一个简洁的助手。"}, {"role": "user", "content": "把下面这段话压缩成一句话：..."} ], temperature=0.3, max_tokens=200 ) print(response.choices[0].message.content)

切换后建议做三件事：第一，用同一批测试用例对比新旧模型的输出质量；第二，记录实际token消耗和费用，验证降价是否真实反映在账单上；第三，观察响应延迟，Sol在缓存命中时应该更快，但首次请求可能因为冷启动略慢。

注意：有些第三方接口的模型名称映射可能滞后，你写gpt-6.1-sol它可能不认。先查接口文档的模型列表，确认名称后再切。如果接口不支持，可以先用官方渠道跑通再迁移。

3. Dots常驻Agent：从“用完即走”到“一直在场”

3.1 常驻Agent和普通Agent的本质区别

普通Agent你肯定用过：打开对话框，输入任务，它执行，给你结果，结束。整个过程是会话式的，会话结束，Agent的状态就丢了。下次你再找它，它不记得上次干了什么。

Dots这次做的“常驻”，核心是三个变化：

• 持久化记忆：Agent有自己的记忆存储，不是存在对话历史里，而是存在独立的记忆层。你上次让它整理的文件、它自己总结的规律、它对你的偏好的理解，都保留下来。
• 后台任务队列：Agent可以接受“定时任务”或“触发式任务”。比如你告诉它“每天早上9点把昨天的销售数据汇总发我”，它就自己排进队列，到点执行，不需要你在线。
• 主动通知：Agent完成任务后，可以通过你指定的渠道（邮件、消息、桌面通知）主动告诉你结果，而不是等你来问。

这三个变化叠加，Agent的角色就从“工具”变成了“助手”。工具是你用的时候才存在，助手是一直在的。

3.2 常驻Agent的架构长什么样

我根据公开信息和自己的搭建经验，画不出图（这里也不让画），但可以用文字描述清楚。一个常驻Agent通常包含这几层：

第一层：接入层。负责接收你的指令，可以是一个聊天窗口、一个API、一个邮件地址，甚至是一个定时触发器。这一层不处理逻辑，只负责“把请求送进来”。

第二层：调度层。这是常驻Agent的核心。它维护一个任务队列，决定什么时候执行哪个任务、优先级怎么排、失败了怎么重试。调度层还负责管理Agent的“心跳”——定期检查有没有新任务、有没有任务超时。

第三层：记忆层。分短期记忆和长期记忆。短期记忆是当前任务的上下文，长期记忆是跨任务的持久化信息。长期记忆通常用向量数据库存储，检索时按相关性召回。

第四层：执行层。调用模型、调用工具、执行代码。这一层是实际干活的地方，也是token消耗的主要来源。

第五层：通知层。任务完成后，通过配置的渠道把结果推给你。

这五层里，调度层和记忆层是常驻Agent和普通Agent最大的区别。普通Agent没有调度层（你调用一次它跑一次），记忆层也很薄（只有对话历史）。

3.3 搭建一个常驻Agent的最小可行方案

如果你想自己搭一个类似Dots的常驻Agent，不需要从零写。我推荐用现成的Agent框架加一个调度器。以下是一个最小可行方案的步骤：

第一步：选框架。LangChain、Dify、CrewAI都可以。LangChain灵活但学习曲线陡，Dify开箱即用但定制性差，CrewAI适合多Agent协作。如果你只是要一个单Agent常驻，Dify最快；如果要深度定制，LangChain。

第二步：加调度器。Python里用APScheduler或者Celery。APScheduler轻量，适合个人项目；Celery重但可靠，适合生产环境。配置一个定时任务，每5分钟检查一次任务队列。

第三步：接记忆存储。用Chroma或者Qdrant做向量存储，存长期记忆。每次任务开始前，从记忆里检索相关上下文；任务结束后，把新的结论写回记忆。

第四步：配通知渠道。邮件用SMTP，消息用Webhook，桌面通知用系统API。至少配一个，否则Agent干完活你不知道。

第五步：部署。常驻Agent需要一直运行，所以不能跑在你的笔记本上（合盖就断）。用一台常开的机器，或者云服务器。如果只是个人用，一个最低配的云主机就够了。

# 一个极简的常驻Agent调度示例（伪代码结构） from apscheduler.schedulers.blocking import BlockingScheduler import requests scheduler = BlockingScheduler() def check_tasks(): # 从任务队列拉取待执行任务 tasks = fetch_pending_tasks() for task in tasks: result = execute_agent_task(task) save_result(task, result) notify_user(task, result) # 每5分钟检查一次 scheduler.add_job(check_tasks, 'interval', minutes=5) scheduler.start()

实操心得：常驻Agent最容易出问题的地方不是模型调用，而是任务重复执行和记忆污染。任务重复执行是因为调度器没有做好幂等，同一个任务被跑了两次。解决办法是给每个任务一个唯一ID，执行前先检查状态。记忆污染是因为把不准确的结果写回了长期记忆，下次检索出来就是错的。解决办法是写回前加一个校验步骤，或者只写回高置信度的结论。

3.4 常驻Agent的安全边界怎么划

Agent常驻之后，它能接触的东西变多了：你的文件、你的邮件、你的日历、你的API。安全边界必须提前划好。

• 权限最小化：Agent只应该有你明确授予的权限。不要给它全盘文件访问权，只给它需要操作的目录。
• 操作审计：Agent的每一步操作都要有日志。它调用了什么工具、访问了什么数据、产生了什么结果，全部记录。出问题的时候能追溯。
• 敏感操作二次确认：删除文件、发送邮件、修改数据这类不可逆操作，Agent应该先问你，你确认了再执行。
• 网络隔离：如果Agent需要访问外部服务，限制它只能访问白名单内的地址。不要让它随便往外发请求。

注意：常驻Agent的“常驻”意味着它在你不在的时候也在运行。如果你给它配了自动执行某些操作的权限，一定要确保这些操作是安全的、可回滚的。我见过有人让Agent自动整理文件，结果Agent把重要文件移到了回收站，等人发现已经过了恢复期。自动操作一定要有备份或回收机制。

4. AMD收购World Labs：芯片厂商的AI战略在变

4.1 World Labs是做什么的，为什么AMD要买

World Labs的核心方向是空间智能和3D世界生成。简单说，就是让AI理解三维空间、生成三维场景、在三维环境里做推理和交互。这跟传统的大语言模型不一样，大语言模型处理的是文本序列，World Labs处理的是空间结构。

为什么AMD要买？因为AI的下一波应用很可能不在纯文本上，而在具身智能、机器人、自动驾驶、游戏生成、数字孪生这些需要空间理解的领域。这些领域对算力的需求和文本模型不同：文本模型拼的是矩阵乘法吞吐，空间模型拼的是几何计算、渲染、物理模拟。AMD的GPU在这些方面有积累，但缺一个“标杆应用”来证明自己。收购World Labs，就是买一个标杆。

4.2 对开发者的直接影响：AMD显卡在AI工作流里的角色变了

以前大家用AMD显卡跑AI，主要是因为便宜。同样的显存，AMD卡价格低不少，但生态差、兼容性坑多。很多人买了AMD卡之后发现，很多AI框架默认只支持CUDA，跑起来各种报错。

AMD收购World Labs之后，情况可能会变。如果World Labs的技术栈深度绑定AMD硬件，并且AMD把它开源或开放给开发者，那么空间智能相关的AI任务在AMD卡上可能反而更好跑。这就像当年某些游戏在A卡上优化更好一样，不是性能绝对强，而是针对性优化到位。

对普通开发者的影响分几类：

• 做文本AI的：短期影响不大，CUDA生态还是主流。但AMD如果借World Labs把ROCm生态做起来，长期多一个选择。
• 做3D/空间AI的：值得关注。如果World Labs的工具链开放，AMD卡可能成为性价比最高的选择。
• 做Agent的：间接影响。Agent如果未来要操作3D环境（比如控制机器人、操作游戏角色），底层算力选择会变多。

4.3 AMD显卡跑AI的现状和实操建议

如果你手头有AMD显卡，想跑AI工作流，目前的现实是这样的：

能跑，但需要折腾。ROCm是AMD的CUDA对标方案，支持PyTorch和TensorFlow，但版本兼容性比CUDA挑剔得多。我的经验是：先查ROCm官方文档的支持列表，确认你的显卡型号和操作系统版本在列表里，再动手。不在列表里的，大概率跑不起来，别浪费时间。

Windows下的支持比Linux差。如果你想认真用AMD卡跑AI，装Linux。Ubuntu是兼容性最好的选择。Windows下虽然也有ROCm版本，但坑多，驱动更新慢。

显存比算力重要。跑AI模型，显存是第一瓶颈。AMD卡的优势往往在同等价格下显存更大。如果你要跑大模型推理，显存大比算力高更实用。

实操心得：AMD显卡跑AI，最怕的是驱动和框架版本不匹配。我的做法是：锁定一个经过验证的版本组合（比如ROCm 6.x + PyTorch 2.x + Ubuntu 22.04），然后不要随便升级。升级之前先看社区有没有人踩坑。另外，AMD的清理工具在换驱动版本时很有用，能避免旧驱动残留导致的各种奇怪问题。

4.4 这笔收购对Agent开发者的间接影响

Agent开发者可能觉得“空间智能跟我没关系”，但其实有关系。Agent的未来形态之一是具身Agent——能操作物理设备、能在三维环境里执行任务的Agent。Dots这类常驻Agent如果未来要接入机器人、智能家居、AR/VR环境，就需要空间理解能力。AMD收购World Labs，是在为这个方向铺路。

短期看，你可以不关心。中期看，如果你在做Agent的长期规划，空间智能是一个值得留意的扩展方向。长期看，Agent和空间智能的结合可能会催生新的产品形态，就像当年移动互联网和GPS结合催生了打车软件一样。

5. 三件事串起来：2026年AI开发者的行动清单

5.1 成本重构：把之前砍掉的功能加回来

GPT-6.1 Sol降价最直接的影响是，你之前因为成本砍掉的功能可以重新评估了。我建议你做一次“成本复盘”：列出你产品里所有因为token成本而妥协的地方——上下文窗口调小了、Agent步骤限制了、批量任务减少了、常驻功能没开——然后按新价格重新算账。

算账的方法很简单：拿你上个月的实际token消耗量，乘以新的单价，看看省下来的钱够不够支撑你加回那些功能。大多数情况下，答案是够的。

5.2 形态升级：从“调用Agent”到“运营Agent”

Dots常驻Agent代表的是一个趋势：Agent不再是你代码里的一个函数，而是一个需要“运营”的服务。你需要考虑它的记忆怎么管理、任务怎么调度、安全边界怎么划、异常怎么处理。这跟运营一个后端服务的思路是一样的。

如果你之前做Agent只是“调一下API拿结果”，现在可以开始考虑：这个Agent能不能常驻？能不能记住上次的结果？能不能在我不在的时候继续干活？这三个问题想清楚，你的Agent产品形态就升级了。

5.3 硬件关注：AMD生态的变化值得跟踪

AMD收购World Labs这件事，短期不影响你的技术选型，但值得放在观察列表里。具体跟踪什么：World Labs的技术是否开源、ROCm是否因此获得更多资源、主流AI框架是否增加对AMD空间计算的支持。如果这三个问题的答案都是正面的，AMD显卡在AI工作流里的地位会明显提升。

5.4 一个具体的行动建议

如果你这周只能做一件事，我建议是：把你的Agent从“会话式”改成“常驻式”。不需要一步到位，先从最简单的开始——加一个定时任务，让Agent每天固定时间跑一次，结果发到你邮箱。跑通之后，再加记忆、再加触发条件、再加通知渠道。一步一步来，比一次性重构风险小得多。

最后分享一个小技巧：常驻Agent的调试比普通Agent麻烦，因为它在你不在的时候运行。我的做法是给Agent加一个“调试模式”，开启后所有操作都写详细日志，但不实际执行敏感操作。这样你可以观察它的行为逻辑，确认没问题后再关掉调试模式，让它真正干活。这个习惯帮我避免了好几次“Agent半夜把文件删了”的事故。