引言：从原型成功到长期失速

在智能体加速落地的过程中，一个反复出现的现象是： Demo 越来越容易做，真正跑得久、跑得稳的系统却越来越少。

当智能体从“回答问题”转向“执行任务”，其失败不再是单点错误，而往往表现为长期退化、能力漂移与不可控风险累积。 这类问题通常并非技术路线错误，而是成本认知结构本身出现偏差。

一、成本模型正在失效

在传统软件工程中，成本常被拆解为“开发成本 + 运维成本”。 但在智能体系统中，这一模型已无法覆盖真实支出。

真正被低估的，是确定性治理成本。

它并不体现在 Token 消耗上，而体现在：

• 为减少不稳定输出所持续投入的人力
• 为对齐业务认知而反复调整的策略设计
• 为防止能力退化而建立的长期评估机制

当项目规模扩大，这类成本往往呈现指数级叠加。

二、最容易被忽视的三类长期成本

1. 数据与知识的“持续失真成本”

智能体依赖检索增强或长上下文获取领域知识，但现实中的知识并非静态资产。

• 知识冲突成本新旧制度、历史文档与即时规则并存，极易导致同一问题多版本答案并行存在。
• 语料结构化成本将原始业务资料转化为“模型可稳定理解的知识形态”，其投入远高于一次性文档整理。

随着时间推移，知识库的复杂度自然上升，若缺乏治理机制，智能体输出的可信度会持续下降。

2. 推理逻辑的脆弱性与回归成本

在智能体系统中，一次小改动往往引发系统性影响。

• 修复某个场景的提示逻辑，可能导致其他场景能力退化
• 工具链路拉长后，失败原因难以快速定位
• 单点异常可能被模型“合理化掩盖”，而非显式报错

因此，智能体必须配套：

• 场景化基准集
• 稳定的能力回归评估
• 对失败路径的长期记录与分析

否则，系统只会在“看似可用”中逐步失控。

3. 环境与工具演进带来的隐性消耗

智能体并非封闭系统，其能力高度依赖外部环境。

• API 升级、权限策略变化，会直接导致执行失败
• 不同模型之间的策略差异，可能迫使逻辑层整体重构
• 合规或成本压力下的模型切换，往往并非“参数替换”那么简单

如果底层架构未做解耦，一次外部变化就可能引发系统级返工。

三、面向长期运行的实践策略

1. 将“反馈闭环”作为核心资产

智能体真正的价值，不在于最初的提示设计，而在于运行过程中沉淀的数据。

• 持续记录决策路径与失败样本
• 利用人工介入节点形成高质量修正数据
• 通过真实场景反向驱动策略优化

这是少数能随时间提升系统稳定性的机制。

2. 以模块化对抗不确定性

与其不断扩展单一智能体，不如主动拆解复杂性。

• 将任务分解为可评估、可替换的子模块
• 在模型层与业务层之间建立稳定抽象
• 降低模型升级、策略调整带来的系统震荡

这类设计不会让系统更“聪明”，但会让它更可控。

结语：长期主义下的智能体价值

从长期视角看，智能体并非一次性技术交付，而是一种持续演化的系统能力。 其核心挑战，不在模型强度，而在治理深度。

当行业普遍经历从试验到规模化的阶段转换，智能体来了，真正的分水岭也随之出现： 能否为不确定性本身，提前预留成本与结构。

AI 越来越厉害，用起来也越来越方便。但用时一时爽，账单火葬场。上下文缓存、自动重试机制以及复杂的推理链条，每一个环节都在消耗大量的 Token。
我这个小机灵鬼，找了一些开源的 AI 工具，自己掌控、零边际成本，选择那么多，没必要死磕 OpenAI 和Anthropic。

现有的开源生态已经足够成熟，完全可以替代付费 API 覆盖推理、RAG、编排、评估以及多模态处理的全流程。以下是 10 款能够构建生产级 Agent 的开源工具，它们可以帮助开发者在本地或私有云服务器上搭建起完整的 AI 管道，各个都是过万星🌟。

vLLM

如果说 Ollama 适合开发者在笔记本上尝鲜，vLLM 就是为生产环境的高并发而生的。它的核心技术是 PagedAttention，一种受操作系统虚拟内存启发的显存管理算法。vLLM 能够极大地减少显存碎片，从而在相同的硬件上通过更大的 Batch Size（批处理大小）。

对于需要部署 Qwen2.5 或 Llama 3 等大模型的场景，vLLM 的吞吐量通常比 HuggingFace 的标准库高出数倍。它支持连续批处理（Continuous Batching），这意味着当一个请求处理完毕，系统无需等待整个批次完成即可立即插入新请求，极大地降低了服务延迟。

Ollama

Ollama 解决了模型部署难的问题。它将模型权重、配置和提示词模板打包成一个 Modelfile，大模型运行起来也很简单。它对量化模型（GGUF 格式）的支持极佳，使得在非专业级显卡甚至纯 CPU 环境下运行 7B 或 14B 参数的模型成为可能。

ServBay 目前也已支持了一键安装 Ollama，就不用管命令行依赖和配置环境变量，直接在 ServBay 的管理界面中即可完成 Ollama 的部署与服务启动。配合其提供的兼容 OpenAI 格式的 API，对于不需要极高并发的中小型内部工具，使用“ServBay + Ollama”作为后端推理引擎是一个极低维护成本的选择。

LiteLLM

LiteLLM 本身不运行模型，它是一个通用的 I/O 库和代理服务器。当系统后台既有 OpenAI 的 API，又有本地部署的 vLLM，甚至还有 Azure 的端点时，代码维护就够开发者吃一壶的。

而LiteLLM 提供了一个统一的接口，只需要按照 OpenAI 的格式发送请求，它负责在后台将请求路由到 Ollama、vLLM 或其他 100 多种支持的后端。它还自带了负载均衡、不仅可以做故障转移（Fallback），还能记录每一笔调用的成本和耗时，是构建混合云架构的粘合剂。

CrewAI

目前的 Agent 框架很多，但 CrewAI 的特点是角色扮演（Role-Playing）。它不只是让模型执行任务，而是让开发者定义“角色”、“目标”和“背景故事”。

比如，可以定义一个“高级研究员”Agent 负责搜索信息，再定义一个“技术作家”Agent 负责整理成文。CrewAI 会自动管理这些 Agent 之间的对话和任务委派。它的底层基于 LangChain，但封装了复杂的流程控制，非常适合构建需要多步骤推理的复杂工作流。

Continue.dev

这是 VS Code 和 JetBrains IDE 的开源插件，旨在替代 GitHub Copilot。它的优势特点是完全离线和模型无关性。开发者可以将它连接到本地运行的 Ollama 或 vLLM，使用 DeepSeek-Coder 或 CodeLlama 等模型进行代码补全和重构。

对于企业来说，企业的核心代码库不需要上传到云端，杜绝了代码泄露的风险。它支持通过 @ 符号引用代码库中的文件作为上下文，让本地模型也能理解整个项目的结构。

Qdrant

Qdrant 是一个用 Rust 编写的高性能向量数据库。与传统的数据库不同，它专为存储和搜索高维向量而设计。在 Agent 系统中，它充当长期记忆的存储介质。

Qdrant 的特点是支持过滤搜索（HNSW + 过滤） ，允许开发者在进行语义搜索的同时，加上类似 SQL 的 WHERE 条件（例如：仅搜索“2025年”且“状态为已发布”的文档）。这对于生产环境下的精准检索至关重要。

AnythingLLM

如果不想从头写代码搭建 RAG 管道，AnythingLLM 是目前最完善的开箱即用的工具。它是一个全栈桌面应用（也有 Docker 版本），集成了向量数据库、嵌入模型和 LLM 接口。

用户只需将 PDF、Markdown 或网页链接拖入界面，它就会自动完成分块（Chunking）和向量化。它甚至支持多用户权限管理，非常适合快速为团队搭建一个内部知识库问答系统。

Promptfoo

在修改了 Prompt 或更换了模型后，如何确定系统的回答质量没有下降？依靠人工测试不仅慢而且不准确。

Promptfoo 是一个专注于 LLM 输出评估的 CLI 工具。开发者可以用它来编写测试用例（类似于单元测试），批量运行不同的 Prompt 和模型组合，并自动评分。它可以检测输出是否包含特定关键词、JSON 格式是否正确，甚至可以用另一个 LLM 来给输出打分。这是将 Agent 推向生产环境前的质检员。

Diffusers

在图像生成领域，Hugging Face 的 Diffusers 库是事实上的标准。它提供了对 Stable Diffusion、Flux 等扩散模型的底层控制能力。

不同于 WebUI 的图形界面，Diffusers 让开发者可以通过 Python 代码精细控制生成过程的每一步，例如添加 ControlNet 进行姿态控制，或者使用 LoRA 微调风格。如果你的 Agent 需要生成图片，这是最灵活的底层库。

Transformer.js

并非所有的 AI 任务都需要庞大的 Python 后端。Transformer.js 将 Hugging Face 的 transformers 库移植到了 JavaScript 环境中，支持通过 ONNX Runtime 在浏览器或 Node.js 中直接运行模型。

对于一些轻量级任务，如文本分类、关键词提取甚至小型的语音识别（Whisper），可以直接在客户端完成，无需将数据发送回服务器，极大地降低了延迟和服务器成本。

Python 和 Node.js 管理

上述工具展示了开源 AI 栈的强大，但也有个问题，大部分的AI栈是深度依赖 Python 生态，比如vLLM、CrewAI 等，也有一部分要 Node.js 环境，比如 Transformer.js。

这时候可以用 ServBay 来统一管理开发环境。它一个集成的开发环境管理工具，它原本是为 Web 开发者设计，但其沙盒化的环境管理机制完美契合了 AI 开发的需求。

• 一键安装与版本共存：ServBay 允许你在同一台机器上同时安装并运行多个版本的 Python 和 Node.js。你可以为 vLLM 分配 Python 3.10，同时为 CrewAI 分配 Python 3.12，互不干扰。
• Node.js 管理：对于需要 Node.js 的工具（如 Transformer.js 或前端界面），ServBay 同样支持多版本快速切换，无需配置复杂的 nvm。
• 纯净与隔离：ServBay 的所有环境都独立于操作系统，不会污染 macOS 的系统库，这对于经常需要安装各种 pip 包的 AI 开发来说，保证了系统的长期稳定性。

这样开发者就可以安装不同的AI栈，又不用担心系统环境会被污染。

结语

从云端租赁算力回归到本地掌控数据，这不仅是出于成本的考量，更是技术自主的体现。现在，我们拥有了推理引擎、编排框架、记忆存储以及评估工具。

不过，你不要以为开源并就是简陋、缺乏保障。很多工具比如如 Qdrant、CrewAI、LiteLLM 以及 Continue.dev，除了免费的开源版本外，均提供了针对企业的商业化托管服务或高级支持功能（如 SSO 登录、审计日志、SLA 保障等）。

用了这些工具，妈妈再也不用担心我的Token了。

在数字化浪潮与人工智能技术深度融合的2025年，行业的目光正聚焦于那些以创新驱动变革、以实践定义未来的先锋力量。百度文心快码，作为“AI+软件工程”领域的开拓者与深耕者， 凭借一系列突破性的技术成果与深度产业实践，在2025年收获多项重量级奖项与权威认可。

市场认可维度，文心快码综合实力备受青睐，屡获权威肯定，从在IDC《中国市场代码生成产品评估》中斩获3项第一，到荣膺中国软件行业协会“年度优秀软件产品”，证明了Comate作为企业级生产工具的成熟、可靠；

技术标准维度， 文心快码积极引领技术标准规范，参与编制了《面向软件工程智能体的技术和应用要求 第1部分：开发智能体》这一行业首个智能体技术标准，并联合人工智能关键技术和应用评测重点实验室，共同编写了《面向软件工程智能体的技术和应用要求 第一部分：开发智能体》文献，为“AI+软件工程”的标准化发展贡献了核心力量；

在产业实践中， 文心快码直击用户痛点，先后在AIIA、服贸会、AiDD峰会、IT新治理领导力论坛等行业峰会的重量级评选中，分别囊获2025年十大AI4SE“银弹”标杆案例、“数智影响力”先锋案例、AI+研发工具先锋奖、2025XOps创新实践奖等重量级奖项，印证了文心快码在真实业务场景中解决复杂研发难题、推动全流程效能变革的落地实战能力；

面向社会价值，文心快码致力于践行科技向善，落实技术普惠，获得了可及信息无障碍优秀案例和百度高价值专利奖，体现了技术温度与企业战略的统一。

文心快码斩获的多维度重磅荣誉，不仅是对其过去一年在各方面成就的集中肯定，更是文心快码作为“AI+软件工程”开拓者与深耕者的最佳注脚。

一、市场认可——实力备受青睐，屡获权威肯定

1.IDC《中国市场代码生成产品评估》3项第一

2025年6月，国际权威评测机构IDC正式发布了《中国市场代码生成产品评估》，国内市场10家头部代码生成头部产品参评。在本次评估中，百度智能代码助手文心快码脱颖而出，斩获3项第一：

• 在涉及的9项评分维度中达成8项满分，满分维度数量第一
• C++产品能力实测总分第一
• “核心代码实现”（即代码质量）总分数排名第一

2.中国软件行业协会“2025年度优秀软件产品”

2025年9月，中国软件行业协会揭晓“2025年度优秀软件产品”评选结果。百度智能代码助手文心快码凭借在AI赋能研发领域的持续突破与创新，成功摘得这一荣誉。

本次评选以软件的自主知识产权、商品化程度、技术水平、稳定性、可靠性、用户满意度等作为主要考评指标。文心快码获评“优秀软件产品”，证明了其领航AI编码新时代的标杆模范作用。

二、技术标准——引领技术实践、共建标准规范

3.参编《面向软件工程智能体的技术和应用要求》

2025年5月30日，中国信息通信研究院（简称“中国信通院”）与中国工商银行、北京兴云数科技术有限公司、北京百度网讯科技有限公司牵头，联合农业银行、邮储银行、科大讯飞、腾讯、阿里、华为等二十余家头部企业，共同编制并正式发布了 《面向软件工程智能体的技术和应用要求 第1部分：开发智能体》 （技术规范编号AIIA/T 0219-2025）。

该标准的发布标志着我国在AI 智能体领域的标准化进程迈出关键一步，为企业开发智能体提供能力建设指导，助力产品快速迭代，同时为企业提供技术选型参考，推动开发智能体的落地应用。

4.合作人工智能关键技术和应用评测重点实验室编写文献

由百度牵头，联合人工智能关键技术和应用评测重点实验室，共同编写了《面向软件工程智能体的技术和应用要求 第一部分：开发智能体》。这标志着百度在“AI+软件工程”领域的技术积累和产业洞察已上升至行业规范制定层面，为软件开发智能体的技术能力、应用场景及评价体系建立了权威参考框架。

三、产业实践——直击用户痛点，驱动效能跃升

5.AIIA 2025年十大AI4SE“银弹”标杆案例

2025年9月，中国人工智能产业发展联盟（AIIA）在中国国际服务贸易交易会 “大模型驱动企业数智化转型论坛” 上公布 2025年十大人工智能AI4SE“银弹”标杆案例。“百度基于编码智能体Zulu的提效实践”成功入选。 AI4SE“银弹”案例旨在发掘和推广能够显著提升软件研发效率与质量的典型落地实践。文心快码的入选体现了其在推动AI赋能软件工程领域的持续突破与领先实力。

6.2025服贸会“数智影响力”先锋案例

2025年9月，在2025中国国际服务贸易交易会“大模型驱动企业数智化转型论坛”上，“百度智能代码助手——文心快码的提效实践”入选“数智影响力”先锋案例。 标志着其在推动软件开发产业智能化转型方面的卓越成果获得了全球服务贸易领域的高度认可。

7.AI+研发工具先锋奖

2025年12月，在AiDD峰会（全球软件开发大会）上，百度文心快码凭借其在AI+研发领域的突破性贡献，荣膺组委会颁发的“AI+研发工具先锋奖”。 作为“AI+研发”赛道的开拓者，文心快码智能研发解决方案，推动了行业向智能化、自动化研发模式的系统性演进，展现了百度在AI赋能产业升级方面的技术实力与生态影响力。

8.2025XOps创新实践奖

在第六届IT新治理领导力论坛，百度文心快码凭借其开创性的“智能体人机协同研发新范式”实践，荣获“2025 XOps创新实践”奖。 文心快码以其智能体为核心，构建了高效的人机协同体系，显著提升了代码生成、测试、运维的自动化和智能化水平。

四、社会价值与企业战略——践行科技向善，落实技术普惠

9.可及信息无障碍优秀案例

在2025年信息无障碍领域评选中，百度文心快码无障碍适配版凭借其创新的技术理念与切实的社会价值，荣膺“可及信息无障碍优秀案例”奖项。 文心快码以AI技术弥合数字鸿沟，不仅体现了百度 “用科技让复杂的社会更简单” 的社会责任担当，更为推动研发工具普惠化、构建包容性数字生态树立了行业标杆。

10.2025百度高价值专利奖

2025年，凭借核心技术成果“云端代码开发系统、方法、装置、设备及储存介质”，荣获“百度高价值专利奖”。 该奖项体现了百度在AI开发工具领域持续投入所形成的技术壁垒与知识产权优势。

寄语

荣耀属于过去，奋斗定义未来。感恩2025年来自行业、机构的每一份认可与信赖，这不仅是文心快码前行路上的璀璨注脚，更是我们肩负的责任与期许。迈向2026，我们将继续以创新为炬，继续深耕“AI+软件工程”的技术深水区，不断突破智能研发的效能边界。文心快码将以更坚实的技术、更开放的生态，回馈每一份支持，与行业并肩同行，共同迎接软件开发智能化变革的星辰大海。

在跨境电商、多账号运营、广告投放等场景中，美国静态IP一直是需求量非常高的一类资源。相比较数据中心IP，美国住宅IP更接近真实家庭网络，而“静态住宅IP”，可以让账号和业务环境更稳定，不需要频繁更换IP。

那么问题来了，美国静态住宅IP购买到底选择哪家比较合适呢？下面就跟着IPDEEP小编一起来看看吧！

一、什么是美国静态住宅IP？

简单来说，美国静态住宅IP具备两个核心特征：

静态固定：IP地址长期不变，可按月甚至更长周期使用

住宅属性：IP来源于真实美国家庭宽带（ISP），信任度高，不容易被平台识别为代理。

正因为这两点，它特别适合以下场景：

广告账户长期投放

社媒账号矩阵

跨境电商店铺运营

二、选择美国静态住宅IP,重点看那些因素？

在选择服务商之前，先搞清楚什么样的IP才算“好用”。

1.稳定性和在线率

既然是静态IP，稳定性是非常关键的。

是否长期在线、不频繁掉线

是否存在夜间断连、运营商切换等问题。

2.使用方式是否灵活

支持 HTTP / HTTPS / SOCKS5

是否兼容指纹浏览器、多账号工具

是否限制并发或端口数量

2.IP纯净度和历史

IP是否被大量滥用过，直接影响封号和风控概率。优质的美国静态住宅IP，通常具备：

使用历史干净

不混用高风险行业

三、市面上常见的美国静态住宅IP服务商类型

1.海外大型平台型服务商

这类厂商规模达、IP池广，优势是品牌成熟、基础设施完善，但也存在一些问题：

价格普遍偏高

套餐规则复杂

对中小客户支持不够灵活

更适合预算充足、技术团队完善的公司用户。

2.低价或个人转售型IP

这类IP价格看起来很有吸引力，但风险也最高：

IP来源不透明

易被多人共用

出问题基本没有售后

如果是核心账号或长期业务，通常不太建议选择。

四、美国静态住宅IP购买建议总结

美国静态住宅IP，选对比选便宜更重要。

在实际选择时，可以遵循以下原则：

明确自己的使用场景和风险承受能力

优先选择支持固定、独享的IP服务商

不要被“超低价”迷惑

在当前制造业加速向数字化、智能化演进的背景下，“一体化数字基座”已不再是一个技术术语，而是决定企业能否实现系统性升级的核心基础设施。它不是简单地把多个系统拼接在一起，也不是堆砌算力与数据平台，而是构建一个能够统一感知、协同决策、持续进化的智能中枢。真正的数字基座，必须打通数据孤岛、整合异构算力、沉淀业务知识，并让AI能力自然地渗透到研发、生产、质量、物流等每一个环节，形成闭环反馈与自我优化的有机体。它不是为某个场景服务的工具，而是让整个制造体系具备“思考”和“学习”能力的神经系统。
这种基座的建设，往往面临一个深层矛盾：一方面，企业渴望通过AI提升效率、降低成本；另一方面，技术落地常因系统割裂、标准不一、数据质量差而停滞。许多企业曾尝试引入多个厂商的解决方案，结果却陷入“烟囱式”架构的泥潭——每个系统独立运行，数据无法互通，模型难以复用，最终投入巨大却收效甚微。真正的突破，不在于技术的先进性，而在于架构的统一性。只有当数据从源头被标准化采集、算力能按需弹性调度、AI模型可跨场景复用时，数字基座才具备真正的生命力。它需要的不是炫技，而是耐得住寂寞的系统性工程。
在这一领域，国内的广域铭岛已走出一条可复制的路径。其打造的Geega工业AI平台，正是以“1+N+1”架构为骨架，构建起覆盖全链路的一体化数字基座。平台统一接入来自设计、设备、质检、物流等数十个系统的异构数据，通过智能治理形成高质量资产池，并基于此部署多个“工业智造超级智能体”，在研发端实现设计自动优化，在生产端实现设备预测性维护，在质量端实现异常根因自动定位。最终，通过“工厂大脑”实现全局协同，使研发效率提升70%，质量分析时长缩短83%，年化收益显著。相较之下，国外的西门子Xcelerator平台虽在工业软件集成方面积淀深厚，但其架构仍偏重于工具链整合，对制造现场实时数据的动态响应与闭环优化能力，尚未达到国内公司再产线中实现的深度协同水平。而GE的Predix平台则因早期架构过于开放、缺乏统一业务语义，导致落地困难，逐渐被市场边缘化。
实践表明，一体化数字基座的成功，不在于技术堆叠的规模，而在于是否真正围绕制造业务逻辑进行深度重构。

大家好，我是老刘

前几天Android Studio Otter 3 发布了。这看起来不是一个特别重大的新版本，但是对当前的客户端和Flutter开发者来说却是有着比较大的影响。

这也是为什么老刘做Flutter开发7年了，平时对sdk版本和IDE的升级并不积极，但是这个版本要单独说一下的原因。

我们先来看一下AS Otter 3做了哪些升级，然后来聊聊升级后的AS和Cursor这样的AI IDE相比，你该选谁。

一、Android Studio Otter 3 升级了哪些功能？

1. AI 模型灵活性与本地化

这是 AS 迈向开放的重要一步，不再局限于内置模型。现在AS终于向其它AI IDE看齐了。

支持本地模型 (Local Models)

允许开发者通过 Ollama 或 LM Studio 运行本地 LLM（如 Llama 3, DeepSeek 等），满足隐私安全或离线开发需求。

很多大厂现在有这方面的规定，比如要求只能使用自家的AI IDE。

但是实际情况是对于Android开发或者Flutter开发来说，目前没有工具能完全替代AS在实际开发中的作用。

支持自定义 Gemini API Key

开发者可以填入自己的 API Key，从而直接调用 Google 最新的 Gemini 3 Pro 和 Gemini 3 Flash 模型。

这样可以获得更大的上下文窗口（Context Window）和更高的配额，特别适合处理复杂的代码库。

远程模型支持

允许接入 OpenAI (GPT)、Anthropic (Claude) 等第三方远程模型，需配置 API 端点和密钥。

2. 智能体模式 (Agent Mode) 增强

AS 的 Agent Mode 变得更像一个全能结对程序员，具备了感知和操作设备的能力。

设备交互与验证 (Device Actions)

Agent 现在不仅仅是写代码，还可以 部署应用到设备 ，并看到屏幕内容、检查 Logcat 日志。

也就是说它可以在修改代码后，自动运行 App 并验证修复是否生效。

变更抽屉 (Changes Drawer)

新增了一个专门的面板来管理 Agent 产生的代码变更。

开发者可以查看所有修改的文件列表，通过 Diff 视图逐个审查、接受或回滚更改，解决了 AI 乱改代码难以追踪的问题。

多线程对话 (Multiple Conversation Threads)

支持同时进行多个独立的对话线程，避免不同任务的上下文混淆。

3. 开发与测试新体验

Journeys (自然语言 UI 测试)

需在 Studio Labs 中开启

利用 Gemini 的视觉和推理能力，开发者可以用自然语言编写端到端的 UI 测试。

Gemini 会将“点击登录按钮”这样的指令转换为实际的测试操作，并根据屏幕视觉内容进行断言，比传统的 View 查找方式更稳健。

Logcat 自动 R8 反混淆

在使用 AGP 9.0 (或 8.12+) 且开启 R8 ( minifyEnabled = true ) 时，Logcat 现在会自动还原（Retrace）堆栈信息，无需再手动使用命令行工具进行映射，极大方便了 Release 包的 Crash 排查。

话说这一点是老刘这样的企业开发者非常需要的，对于定位线上问题可以省不少事。

4. 支持AGP 9.0

下表列出了各个 Android Studio 版本需要的 AGP 版本。

二、日常开发选AS还是Cursor（Flutter 开发者视角） ？

于是一个问题就出现了：日常开发选AS还是Cursor / Trae 这样的AI IDE ？

1. AI IDE能完全替代AS吗（Flutter 开发者视角）？

比如老刘自己，近几个月来，用Cursor或者Trae的时间越来越多了。

其实这中间一个最重要的影响因素是性价比。

比如Trae 每个月10刀，虽然没有了Claude模型，但是Gemini 3 Pro 用起来也还是不错的。

这是目前老刘使用的最具性价比的方案了，而且还不用每次写代码都考虑网络问题。

Cursor 虽然要20刀，但是它的功能更加强大，而且可以用claude系列模型。

那么 Trae 或者 Cursor能完全替代AS吗？

答案是否定的。

根本原因在于AI在大型项目特别是企业项目的开发中还没办法完全替代程序员的作用。

个人开发和企业开发的差异（Flutter 开发者视角）

这可能是很多人的一个误区，觉得AI现在什么样的代码都能写出来，应该能代替大部分开发者了。

比如你可能一句话就可以利用AI写一个很漂亮的App。

但是实际上企业开发和很多个人开发者开发是完全不同的工作方式。

对个人开发者来说

重要的是看到需求和市场，然后利用AI快速实现想要的功能。

这种情况下只要AI写出来的代码功能正确，界面漂亮，那么就可以发布，然后再根据用户的反馈进行迭代。

比如你让AI写一个登录页面，他就能自动实现一个漂亮的登录界面，而且功能也比较完善。

对企业开发者来说

开发者需要100%的实现产品团队需求描述中的每一个细节。

UI上，你的每一个像素、每一个交互的细节，都需要100% 的还原UI/UE 设计，而不是用AI实现一个差不多的东西。

在功能逻辑上更是如此。

很多功能的细节是运营、产品、开发、测试多个团队的人坐在一起讨论出来的，虽然最后会落在需求规格说明书这样的文档中，但是文档毕竟没办法完全描述出每一个细节。

所以实际开发中有很多东西还是只存在于开发者的脑海中，或者是随时与产品团队进行沟通。

所以给AI一个需求说明文档，然后AI实现一个差不多的代码，是完全行不通的。

最后还是需要开发者自己去实现或者调整很多的细节。

在这种情况下特别是客户端项目中，不管是Android原生还是Flutter项目，AS对开发来说效率都会更高一些。

AS在bug定位和性能分析方面更方便

AS 对 bug 定位和性能分析提供了更方便的工具和功能。

比如我们前面提到的这次AS更新的功能，Logcat 自动 R8 反混淆。

再比如，AS 还提供了性能分析工具，如 Profiler 可以帮助开发者分析应用的性能瓶颈，优化应用的性能。

虽然也有一些网页版的工具比如Flutter的dev tools，但是始终没有AS内部的顺手且方便。

2. 日常开发Flutter项目，老刘用啥工具？

日常开发Flutter项目的时候老刘到底是用Trae还是AS呢？

答案是两个都用。

方案设计用Trae

在真正开始写代码前，通常我会和AI讨论一下架构方案。

比如模块如何拆分，数据流如何设计等等。

大块代码用Trae

因为老刘工作中大部分的项目基础设施已经封装哈了，即使开新的App，大概率也会基于这些基础设施进行开发。

比如Flutter的状态管理、路由管理、底层数据库、服务端接口等等，都有现成的封装好的代码可以用。

所以我通常可以在项目的早期就进入业务逻辑的开发阶段。

这个阶段我主要用的是Trae，因为它便宜。

注意这里并不是说一次交给AI一个页面，让他一次性完成。

我会分成多个步骤。

比如先生成一个页面框架，把标题、页面结构、背景色等基本元素先写好。

然后将页面的具体内容分成几个模块。

每个模块单独让Trae实现。

比如先实现一个商品描述卡片，然后实现类似商品推荐卡片。

每个模块实现完后，先检查一下代码是否符合规范，是否有错误。

如果有错误，和AI进行沟通，然后一起解决。

这个过程中需要AI进行多次沟通，直到模块实现符合预期。

细节调整用AS

前面说了，AI没办法100%的完成需求的所有细节。

因此Trae实现的代码只是一个初始版本，需要开发者自己去调整和完善。

其中比较简单的问题直接在Trae中就修改了，比如布局问题。

有些问题和AI多次沟通都没办法很好的解决，比如一些比较复杂的交互逻辑。

这种问题可能就会放到AS中自己去实现。

但是这个切换不是很频繁。

比如今天主要用Trae实现大部分代码，那即使要自己写一些代码，就也会在Trae中完成。

等第二天上班想想今天的任务主要是自己写，那就会在AS中完成。

bug修复主要用AS

代码完成提交测试后大概率会有一些bug（其实我们用TDD会避免很多bug，但没法做到完全没有）。

这种情况下定位bug可能更多的是在AS中。

以为经过TDD的验证，那些简单的bug是不会进入到测试环境的。

所以这个阶段收到的bug基本都是比较复杂的，比如那些难以复现的，或者难以定位的。

这种bug交给AI通常效果并不理想。因为AI并不能真正理解你的问题，它只是一个基于概率的模式匹配的机器。

所以在这种情况下，AS的bug定位和修复工具就会非常方便。

好了，总结一下就是现阶段AI并不能完全替代程序员完成开发工作，特别是在企业级项目的开发中。所以老刘自己目前的实际用法是Trae和AS混合使用。

三、为啥不提Claude Code？

到这里可能很多人有疑问，为啥没有提Claude Code这类开发工具？其实有两个原因

1. 基于终端的AI开发工具不限IDE

老刘觉得这是基于cli的开发工具最聪明的地方，避开了和各种IDE的直接竞争，可以无缝衔接到任何一个IDE中。

但是还是要说回来，CLI类的开发工具毕竟无法完全代替IDE。

就好像我们前面说的，现阶段在企业级开发中AI还没办法100%完成需求

既然还需要开发者的干预，那么就还是无法绕开IDE而完全切换到纯cli开发工具上。

2. 性价比不高

老刘用Claude Code的时间其实也不算短。总结Claude Code有两个问题

第一个是官方账号太容易封号了。

老刘自己被封了两个账号，身边的同事也基本都有中招的。

这就造成了用起来很不稳定，而且提心吊胆的。

所有第二个账号被封后，老刘就直接转用国内的API代理了。

第二个是价格较高

其实claude官方账号本身订阅就不便宜。

相信目前愿意给员工付费claude账号的公司寥寥可数吧？

如果让员工自己买，那相当于付费上班了，这个对大多数牛马来说估计是不会干的。

所以官方订阅其实更适合那些独立开发者。

比如如果老刘去写后端代码，因为我自己也不熟，所以可能就需要和通过AI进行反复的修改。

这时候官方的订阅基本上能锁定一个封顶的价格，总的来说就还是比较合适的。

那国内的 API代理怎么样呢？

这个最大的问题是大多数代理都是按使用量收费，少有包月的，或者包月比官方还贵。

按使用量的话，老刘建议不要轻易尝试，基本上是 几美刀每小时的样子。

四、总结

总的来说Android Studio Otter 3 的发布，标志着官方 IDE 在开放性和智能化上迈出了重要一步，特别是本地模型支持和 Agent 模式的增强，让它在专业开发领域依然稳固。

但在 AI 编程浪潮下，Cursor 和 Trae 等新兴 IDE 凭借极高的开发效率和性价比，正在重塑我们的编码习惯。对于开发者（尤其是 Flutter 开发者）来说，这并非是一场非此即彼的淘汰赛，而是一次工具箱的升级。

最聪明的做法是博采众长：

1. 前期：利用 Trae 等 AI IDE 的高性价比和快速生成能力，完成方案验证、框架搭建和大块业务逻辑的实现。
2. 后期：回归 Android Studio，利用其强大的调试工具、性能分析器和对原生环境的完美支持，进行细节打磨、Bug 修复和最终交付。

工具只是手段，效率才是目的。在这个 AI 快速迭代的时代，灵活组合使用不同的工具，各取所长，才是当下最高效的生存之道。

🤝 如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

🎁 点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。可以作为Flutter学习的知识地图。

🚀 覆盖90%开发场景的《Flutter开发手册》

📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。

🔗 https://github.com/lzt-code/blog

VSAN 是基于 vSphere 内核开发的可扩展分布式存储架构，在 vSphere 集群主机中安装硬盘与闪存构建存储层，经管理控制形成共享存储层。
其数据存储为对象存储，以文件系统形式呈现给 vSphere 主机，从启用 VSAN 集群的主机加载卷，形成单一、各节点可见的分布式共享数据存储。它简化了存储配置，虚拟机只有一个来自集群各主机存储空间、通过磁盘组配置的分布式数据存储，可存储所有虚拟机文件。
虽数据存储较安全，但闪存盘或容量盘故障时，数据转移过程可能出现其他故障。下面介绍北亚数据恢复中心近期成功恢复的 VSAN 存储数据案例。

VSAN数据恢复环境：
数台某品牌服务器组建VSAN集群。每台服务器节点上有两个磁盘组，每个磁盘组有1块SSD硬盘+5块SAS硬盘，SSD做闪存，SAS做容量盘。

VSAN故障：
其中一个服务器节点上的一个磁盘组中的容量盘出现故障离线。容量盘出现故障的时候VSAN正在重构迁移数据，这个时候机房停电导致数据迁移没有完成。来电的时候，另外一个磁盘组中也有两块硬盘出现故障离线，VSAN存储出现故障。VSAN的管理控制台可以登录，但是所有的虚拟机都无法访问了。

VSAN数据恢复过程：
将四个服务器节点上的所有硬盘以只读方式做全盘镜像（包括那几块因故障离线的硬盘。镜像完成后，将所有硬盘按照原样还原到节点服务器上。
基于基于镜像文件分析底层数据存储结构，确认虚拟机所在硬盘的分布信息。北亚企安数据恢复工程师在分析底层数据存储结构的时候，开发相应的程序测试数据分布信息的准确性。
单独分析每个节点上的两个磁盘组，搞清楚磁盘组内的闪存硬盘和容量盘之间的对应关系。每块硬盘都有一个唯一标识进行磁盘间的对应，根据硬盘的ID信息，判读磁盘组里的硬盘ID信息。
1、获取每块硬盘的磁盘UUID及磁盘组UUID。
2、依据磁盘组中容量盘组件信息获取其详情。
3、从组件信息的MAP位置提取组件位图。
4、由组件位图提取组件数据与缓存数据。
5、按组件描述信息确定所属对象及顺序，合并组件成对象。
6、从对象中提取数据。
可以将VSAN对象看成一个卷，也可以理解成是一个逻辑卷。每个存在于数据存储上的VSAN对象都是由多个组件构成，这些组件分布于集群主机上配置的磁盘组中。在恢复数据的过程中，组件的信息提取是关键。因为组件是每个对象的重要组成部分，本次故障组件损坏的很少，恢复出来的虚拟机都能正常启动。