Claude Code WebUI

撰稿：李文朋

编辑：王一鹏

最近，“Meta 以 20 亿美元收购 Manus”的消息传得很热。

Manus 曾被嘲讽“套壳”，但业内人士认为，虽然 Manus 整体架构和理念不算颠覆式“新”，但在任务连通性、容错、回退机制等实现上，极度考验工程能力，远不是“换个皮”那么简单。

在 Manus 创始团队与媒体的最近一次访谈中，联合创始人季逸超提出目前 Manus 定位只是一位“通用型助手”，帮普通人把复杂工作流做完，不能完全替代用户本身。这也是因为在 ToC 场景里，普通用户对体验要求很苛刻——慢一点不行，错一点也不行，Manus 团队很清楚这一点。

如果说 ToC 用户已经够“难伺候”，那 ToB 客户对 Agent 的要求只会更高：一方面，企业希望 Agent 真正“上生产”，意味着要接入复杂的权限体系、业务系统和合规要求；另一方面，任何一次错误操作、脏数据写入、流程走错，带来的代价都远比个人用户高得多。

所以会看到，过去一年很多企业在这条路上吃了不少苦：投入人力、投入预算，最后做出来的 Agent 用不了。MIT《2025 年商业 AI 现状》报告里提到，约 95%的生成式 AI 试点项目很难进入生产环境，很多最终都卡在上线前后。

问题出在哪？就在于这些一连串的工程难题。

比如代码标准不统一、系统接口五花八门、工具调用不稳定、开发周期被拉得很长；数据资产混乱、想用调不出；安全合规和权限管理一碰就痛；甚至出现“越用越退化”的优化难题。

说到底，并不是模型不行，也不是工程师不会做，而是整个 Agent 开发还不够成熟，大家还在摸索阶段，没有提前规划一套更清晰、更稳定的“做法”。

所以，国内的云厂商开始认真思考一个问题：到底怎样才能帮助企业把 Agent 的难题解决掉？有没有一种更适合落地的开发范式？

2025 云栖大会上，阿里云 CTO 周靖人就曾提出过「AI 时代的 Agent 开发范式」。而在 1 月 7 日，阿里云百炼对“1+2+N”体系和开发范式做了一次更系统的升级，把它落成一个工程化的体系。

这套“1+2+N”体系的想法并不复杂，本质是把 Agent 落地拆成三层：

稳底座（1）：把模型和云资源这些基础能力做稳定、可扩展、可治理。地基不稳，再漂亮的 Agent 也只能停在 PoC。

定范式（2）：给企业一套把 Agent 做成“工业产品”的开发与运行体系，能开发、能部署、能迭代，交付不再反复折腾。

理杂活（N）：把真实业务里最难、最碎、但最致命的集成、权限、评测、成本这些“脏活累活”，做成可插拔的组件，让企业能按需拼装。

从这个角度看，这次阿里云百炼迭代背后体现的是一种更务实的方向：要用更工业化的方式，让企业的 Agent 在真实业务里跑起来。

一、“N”：通用大方案，不如啃硬骨头的“高手组件”

经过大量 Agent 的试错，企业如今在启动一个 Agent 项目时，最先拎出来掂量的往往不是模型，而是数据怎么处理与调用、安全问题能不能搞定、上线后怎么评估和优化。

这些硬问题不先解决，再漂亮的 Agent 构想也很难真正走进生产环境。而在阿里云百炼的“1+2+N”体系里，“N”恰恰就是优先来啃这些硬骨头的。

更关键的是，这一次“N”做了很大的升级：它把落地过程中那些最常见、最难啃、最容易反复踩坑的环节抽象出来，沉淀成一组可插拔、可组合的模块化组件。Agent 开发的难题看起来五花八门，但很多难题其实有共通的解法，可以被提炼、被复用。

“N”组件的存在，可以让企业缺什么就用什么、按需组合，把时间花在业务价值上，而不是重复造轮子。

这次升级里，一个直观的变化在应用广场：阿里云百炼把同类 Agent 做成了十多个精选合集，提供新的多模态模板，支持免登录体验，也能一键调用 API，把“试试到跑起来”的路径压得更短。

真正决定“能不能落地”的挑战，还有数据连接与知识管理、安全与权限控制、可观测与持续优化等问题。

企业做 AI 转型，数据治理永远是“卡脖子”环节。尽管大家都知道数据重要，但真落到工程上，标注、清洗以及让模型读懂私有数据的成本极其高昂。

目前，企业内部约 80%的数据以 PDF、图像、视频或会议录音等非结构化形式存在。据 IDC 预测，这些数据多处于“不可检索、不可复用”的沉睡状态。随着全球数据量预计在 2026 年激增至 221ZB，如何将这些碎片资产转化为 Agent 可调用的知识，成为企业发展的关键。

阿里云百炼的思路是把这条链路做成“工具化”：用多模态 RAG、多模态数据库、Connector 连接器，把数据处理变成更工业化的流水线。

多模态数据库通过智能解析、分类归档，打破图像/音频/视频等模态壁垒；多模态知识库 RAG 不再局限于纯文本，支持数十种格式的高精度解析，包括扫描件 PDF、复杂报表、音视频会议记录等。

在 Workflow 层面添加多模态文件处理与生成节点，同时提供覆盖 Chunking、Embedding、（多模态）Embedding、Rewrite、Retrieval、ReRank 等在内的向量化全流程能力，用于检索与消化企业数据资产。

百炼平台还提供开箱即用的 RAG 工具，企业无需自建复杂的向量库与检索链路，也能获得高性能的知识检索与生成能力。

把知识库做起来只是第一步。要让 Agent 真正有用，它就得能接入实时数据。然而，长期以来 ERP、CRM 等异构系统间的集成成本高昂，导致 65%的企业受访者认为业务系统沦为新的“数据孤岛”。

百炼平台推出的 Connector（企业级数据连接器），就是想把这个门槛降到最低。

通过 Connector，企业可以一键对接飞书、语雀、MySQL 及 OSS 存储；连上之后，这些数据既能直接喂给知识库，也能驱动工作流跑起来；平台还提供数十种预置工具（Tools），支持用自然语言直接查询或检索数据等。

当然，数据一旦接进来了，真正棘手的问题也随之出现：权限边界与责任归属难题。

长期以来，很多 Agent 在企业业务中多以匿名形式存在。这种“身份透明”导致操作链路难以溯源，不仅无法明确执行指令的主体，更埋下了越权操作的隐患。

为此，百炼平台引入 Agent Identity 组件，将 Agent 纳入企业身份治理的范畴。

通过集成 Okta、EntraID 等主流系统，平台为每个 Agent 分配数字身份，使其行为从孤立的匿名调用转变为绑定主体、可供审计的合规操作。

百炼平台也将传统的“常驻权限”升级为“按需授权”仅在执行任务时获得短期令牌，任务结束权限即刻回收。

配合权限降级机制，Agent 的边界被严格限制在用户授权范围内，确保无法越权。全链路审计日志则让每一步决策都透明可查，解决了企业“敢不敢给权限”的顾虑。

针对执行环境安全，百炼平台也构建了 Sandbox（沙盒）物理隔离屏障。当 Agent 处理外部代码或第三方数据时，系统可以利用虚拟化技术将其限制在独立空间内，精简系统调用并严控网络访问。

每一个任务会话均在“即用即弃”的容器中运行，执行完毕立即重置，彻底阻断了数据残留与交叉污染。平台同步引入实时监控与会话回放，一旦监测到异常行为将立即终止任务。这种设计为 Agent 提供了“受控下的自由”：在屏障内保持灵活性，在边界外确保系统安全。

而当 Agent 真正跑进业务之后，新的共性难题也会浮现：怎么评估、怎么持续改进。

与传统软件不同，Agent 的执行具有非确定性：即便输入相同，也可能因模型的随机性、工具调用顺序或上下文波动产生不同的输出。这导致开发者难以追踪 Agent 决策逻辑，在任务失败时无法精准定位是模型、工具还是流程缺陷。

百炼平台通过 Trace（可观测）与 Evaluate（评估）组件，实现了从“黑盒”到“透明”的转变。

Trace 组件提供完整的执行轨迹追踪，清晰复现了从思考（Thought）、行动（Action）到观察（Observation）的每一步。开发者可以判断哪一步耗时最长、哪个工具失败率最高，或是在哪个环节陷入了逻辑死循环。

结合 Token 消耗、响应速度等量化指标，这些数据可通过 Grafana 进行可视化监控，构建起实时的生产环境观测能力。

基于此，Evaluate 则建立了体系化的评价标准。

在任务完成度评价方面，百炼平台可以通过衡量目标满足率与输出质量对 Agent 进行评分；并支持“模型评测（LLMasJudge）”、专家打分与人工复查相结合的混合模式，对失败任务进行深度归因。

可以说，基于日志（Logs）、指标（Metrics）与追踪（Traces）的三大支柱，百炼平台设计了一个“评估—优化—验证”的持续迭代闭环。这种由数据驱动的迭代机制，也驱动着 Agent 实现“越用越好用”的工程闭环。

相比于自建底层架构，直接调用百炼平台的成熟组件能让开发周期缩减数倍。以 RAG 系统为例，以往搭建搜索和解析链路需要数周，现在利用多模态 RAG 组件，几个小时就能跑通。

企业不需要为每个 Agent 单独开发身份认证或数据接口，一套 Agent Identity 就能管好所有 Agent 的工号，一个 Connector 就能接通全公司的数据源。

放在阿里云百炼“1+2+N”体系中，组件化正填补模型到业务之间的最后一块拼图：模型提供计算力，开发范式定好流程，而这“N”个组件则专门负责解决数据怎么连、权限怎么划、效果怎么评、安全怎么管这些具体的“杂活”。

二、“2”：“下一代”Agent，需要新开发范式

“N”组件把坑填平，只解决了“这事能不能接得上、管得住”。企业真正要把 Agent 变成长期能用的工业生产能力，还得解决另一个现实问题：怎么开发、怎么协作、怎么迭代。

阿里云百炼“1+2+N”体系里的“2”，就负责这一点，它涵盖两种开发方式（低代码+高代码），以及配套 Agent 开发平台，通过同一套平台和运行时，分别服务两类人、两种交付方式。

为什么要做成“2”种模式？因为企业落地 Agent 的过程，基本就是两条路同时走：想快速试点、尽快看到效果，低代码更省事、更快；真要进核心业务、对接复杂系统，高代码才够灵活、够深。

更现实的是，企业在代码协作上存在长期的“割裂”：低代码不够用，高代码效率低。产品经理用低代码搭建的草案，往往需要技术团队用高代码重新开发，而这种重复劳动会导致业务逻辑在传递中失真。

为了让 Agent 更快、更深地融入业务，百炼把低代码和高代码“打通”：企业可以从低代码起步做验证，再逐步演进到高代码做优化，形成一种更自然的渐进式开发，让真正懂业务的人与懂技术的人有机协作。

据 Gartner 的预测，到 2028 年，企业里相当一部分 Agent 应用会由业务人员主导搭建。双开发模式很可能会成为 Agent 走向工业化落地的一种主流形态。

但“2”的意义还不止是“怎么写代码”。更重要的是：下一代 Agent 本身就需要新的开发范式。

过去的一年，很多企业里的 Agent 实际上还停留在比较“表层”的形态：一种是以提示词工程为核心、更多承担辅助角色的 Copilot；另一种是能处理重复流程、严格按预设步骤执行的“数字员工”。它们能提升效率，但往往缺少主动规划与闭环执行能力。

Agent 不应仅“被告知怎么做”，而是“应该主动思考怎么做”。

因此阿里云百炼提出了 Agent2.0：未来的 Agent 要能围绕目标自主规划，把复杂问题拆成可执行的小任务，过程中还能根据反馈调整策略，最后交付更稳定、质量更高的结果。

按照这个定义，Agent2.0 的核心链路是“规划—执行—反思”。

而现实里很多 Agent 开发失败，问题往往是开发范式还停留在老路上。传统那种线性链路（用户 →Agent→ 模型 → 输出）有三个硬伤：没有规划，就很难应对动态场景；没有反馈与纠错，走偏就很难拉回来；没有长期记忆，交互体验容易断裂。

为了能承载 Agent2.0 的生产级落地，百炼平台对开发范式做了系统升级：AgentScope 从过去偏“开源写代码”的工具形态，演进为覆盖 Agent 全生命周期的工业化开发平台。

第一步，是把“上手门槛”压到尽量低。

一方面，AgentScope 做了对主流模型能力的统一集成，内置 100+预训练模型，拿来就能用。

另一方面，百炼平台提供了一批可复用的智能体库，比如交易智能体（EvoTraders）、调研智能体、金融分析智能体、数据科学智能体（Data-Juicer）、浏览器使用智能体、语音智能体等，减少从零开始的成本。

第二步，是围绕更高级的 Agent2.0，把“协作与执行”能力补齐。

AgentScope 主要通过三块来支撑：

多智能体编排：引入基于 Actor 模型的分布式架构，支持多个专业 Agent 的并行协作与自动调度。研究表明，协作模式任务成功率比单一 Agent 高出 90.2%。

智能体上下文管理（长期记忆）：深度适配 Mem0、ReMe 等记忆系统。使得 Agent 能够自主存储并检索历史交互中的关键信息，在后续任务中实现能力的持续迭代。

工具调用能力：全面兼容 StreamableHTTP、SSE、STDIO 等主流接口标准。通过支持 AnthropicAgentSkill 规范，在运行时即可动态加载新工具或移除冗余资源。

在工具调用这层，ReAct 这类“边想边做”的范式，也被不少实践证明更容易形成任务闭环：学术基准测试中，ALFWorld 任务只需 2 个示例即可达到 71%的成功率，高于强化学习模型的 37%；在复杂任务中，准确率相较纯 FunctionCalling 提升约 15%–20%，成本比 CodeAct 低 78.9%。

在 Agent2.0 优化与部署阶段，阿里云百炼通过 AgentScope-Studio+AgentScope-Runtime 打通了全生命周期的工业化链路。

AgentScope-Studio 可通过自定义多维表现指标，评估工作流设计的合理性；提供从输入到输出的全链路追踪与可视化，让 Agent 行为与决策过程实现“可观测、可复盘”。

百炼平台利用评测结果持续改进，让失败样本成为训练资产，形成“评测→优化→验证→再优化”的迭代闭环，实现从“盲目调参”到“数据驱动优化”的范式转换。

在落地部署环节，AgentScope-Runtime 支持 Docker、K8S、ACK、Serverless 等多种部署形态；通过 Agent-as-a-Service 将 Agent 封装为可独立调用的 API 服务，兼容 A2A 与 ResponseAPI 等协议，便于集成、弹性扩缩与快速迭代。

如果把阿里云百炼的开发范式拆开来看，其实就是从“构建”走向“运营”的一个完整闭环。

前半段构建，重点是更快、更省力地把东西搭起来：

用可选智能体模板减少重复劳动；用多智能体编排与工作流把复杂任务拆成可协作的子任务；用高低代码一体化实现统一开发与交付；通过 ReAct 等方式完成多任务的规划、执行与自我纠偏，再结合用上下文和长期记忆支撑长链路执行等。

后半段上线运营，就是做让它智能地跑起来：

用可观测和自动化评测把效果变成可量化的指标；打通真实系统和数据源，拿到反馈并持续优化；在企业既有基础设施上实现更便捷的部署与稳定运维；同时借助 Identity、模型单元专属部署、机密推理等能力，把权限、安全与合规治理补齐。

这套开发范式的最大亮点，就是它统一按照“工业级 Agent2.0”的标准做事：高效的开发体系+可持续的反馈闭环+便捷可靠的上线部署。

三、“1”：模型优势之外，深挖“模型服务”工程

最后，无论是组件化拼装，还是低/高代码协作，最终都要落在同一个问题上：模型调用能不能稳定、能不能扛流量、能不能控成本、能不能过合规。

所以“1”是整个体系的地基——模型与云服务底座把推理服务、弹性、部署形态与安全边界做成统一供给，保证上层“能跑起来，也跑得久”。

很多企业在用 Agent 的过程中，卡住的往往不是“模型会不会”，而是一些更现实、更工程的问题：1）延迟、并发、稳定性跟不上真实业务流量；2）成本容易失控（链路长、多轮工具调用、重试一多就更明显）；3）部署和合规麻烦（私有化、混合云、权限边界、数据隔离等）。

在调用模型的时候，企业最关心的也无非就两件事：成本与性能。为此，百炼平台提供了一套云资源调度组合拳：“异步调用+闲时调度”。

以前搞大规模的数据清洗、标注，或者是分析长视频，这些任务不仅计算密集，而且耗时漫长。最头疼的就是走“同步调用”，跑到一半接口超时了，任务断掉，前面全白干。

有了异步调用就省事多了，它像寄快递一样，你把任务丢给后台，拿个任务 ID，就可以去干别的。不用在那儿死等结果，等服务器处理完了你再回来取就可以。

而“闲时调度”更像“错峰用电”：不着急的任务挪到资源空闲的时候跑，单价更划算，整体资源利用率也更高。阿里云百炼官方给出的数据是，动态调度后闲时推理成本可降低 50%。对需要处理海量数据的企业来说，这种节省是实打实的。

此外，阿里云百炼这次把“模型服务能力”也做了系统升级，主要围绕四块：模型后训练、专属模型单元部署、平台可观测、推理安全防护，系统性地”深挖“模型的服务能力。

先从选型说起。百炼平台把模型体验中心做了结构性重构，把在线模型的能力做成更直观的“能力图谱”，支持文本、视觉理解、图像/视频生成、语音交互等全模态体验。

这样企业就不用靠猜，也不用“盲选”，可以在平台上直接对比不同模型在具体场景下的表现，再做选择。

模型选定之后，是否“实用”往往取决于后训练。很多企业真正需要的不是通用能力，而是用自家数据和业务知识微调出来的“专家模型”，这才更贴近业务，也是企业的核心壁垒。

模型训完后，真正容易被“拦住”的常常是部署。自建集群运维复杂、成本也难估：为了应付峰值不得不预留一堆算力，平时又闲着浪费；多租户环境下的数据隔离和性能争抢，会让企业心里不踏实。

阿里云百炼推出“模型单元”部署，其实相当于给企业开了条“专属通道”，减少资源争抢带来的不确定性，让高并发和低延迟更稳定。

同时提供全托管的 Serverless 方式：系统会跟着实时流量自动扩缩容——忙的时候自动扩，保证体验；闲的时候自动收，尽量省成本。

官方给出的测试数据里，模型单元部署相对传统自建集群方案，推理性能提升超过 1.3 倍，并发能力提升超过 1.5 倍。对企业来说，这类提升的意义很直接：同样的业务量，成本更低性能更好。

此外，调用模型处理数据时，最难绕开的是安全——尤其在金融、医疗、法律等高敏行业。很多企业不是不想用，而是卡在一句话：数据给到模型，会不会出事？

为此，百炼平台推出模型“机密推理服务”，依托三层安全架构，为企业构建起全链路的数据保护围墙：

第一层是基于 CPU/GPU 硬件可信执行环境的机密计算能力，将模型推理运行在硬件隔离的安全区内。即便云侧其他组件遭受攻击，敏感数据也难以被窃取或泄露。

第二层是端到端加密的可信链路：实现了从用户端到云端计算中心的全程加密传输。数据在加密状态下进入 TEE 区域处理，计算结果在加密状态下返回，确保数据在“流动”与“处理”的全生命周期中始终处于保护伞下。

第三层是公开审计的可信服务：平台提供可验证的身份与安全能力证明。企业不仅能自主校验服务安全性，更能以此作为合规背书，向管理层、审计机构及客户证明其 AI 系统的高安全性。”

在使用体验上，机密推理被做成了“一键交付”的形态：企业只需要在模型库中选择支持机密推理的版本，一键部署到 TEE 隔离环境，就能直接调用机密推理服务来处理敏感数据。

放在一起看，这次升级是在原有模型性能优势之上，又补上了几块关键拼图：云资源调度、后训练、模型单元化部署、机密推理安全体系等。几块一起发力，让大模型调用变得更实用、更省钱，也更安全。

四、没人愿意再“从零开始”，阿里云百炼 Agent 平台企业版已发布

从市场角度来看，政企、金融、医疗等行业在采购云服务时，始终受困于一种不完美的平衡。

公有云上手快、性能强，但数据边界与合规要求是跨不过的门槛；私有化部署虽有安全感，但往往陷入“模型、工具、流程”极其复杂的运维战泥潭，开发周期长、技术更新慢。

1 月 7 日，阿里云百炼企业版的发布，为市场提供了一个既保留数据主权，又拥有云端顶级效率的方案。

企业版支持专有云、本地化及 VPC 隔离，百炼平台将云端的成熟能力“下沉”至企业环境。更重要的是，百炼平台企业版支持源码级交付。这不仅仅是技术开放，更是给予企业自主演进的确定性。

企业不再需要买一堆零件回去组装，而是直接获得一个在自身安全边界内运行的 Agent 基座。

事实上，企业版也并非新功能的简单集合，而是将百炼平台“1+2+N”体系（顶级模型、成熟范式、核心组件）封装为完整的交付体：

双代码统一：兼顾业务验证的敏捷性与复杂逻辑的深度定制。

多模态 RAG：激活企业沉睡的音视频与文档资产，转化为实时知识。

Trace 与 Evaluate：将 Agent 的黑盒行为拉到台面上，让调试与迭代成为标准工序。

大规模组织的管理诉求：企业版强化了多租户部署、SSO 账号集成以及细粒度的权限审计。这些功能解决了 IT 部门的核心忧虑——让 Agent 的应用在组织内部不仅“能跑通”，更“可治理”。

一个行业走向成熟的标志，是目光从技术指标移向业务价值的“深水区”。

阿里云百炼 Agent 平台企业版，本质上在扮演“AI 时代技术中台”的角色。从行业趋势上看，未来企业大概率将不会从零开始建设 AI 能力，而是直接基于一个完整、成熟的技术中台起步。

这意味着，在一年的野蛮生长后，留给企业 AI 试错的窗口期正在关闭。

展望 2026 年，Agent 应用爆发增长几乎已成共识。Gartner 预测，到 2026 年底，40%的企业应用将集成任务型 AI agents（相比 2025 年不足 5%），这也标志着 Agentic AI 正从概念走向主流生产环境。

对阿里云这样的全栈人工智能服务商而言，这将是多年技术积累转化为业务增量的红利期；对使用模型与 Agent 的企业客户而言，也将是 Agent 正式进入“拼效率、拼落地”的竞争元年。

撰稿：李文朋

编辑：王一鹏

最近，“Meta 以 20 亿美元收购 Manus”的消息传得很热。

Manus 曾被嘲讽“套壳”，但业内人士认为，虽然 Manus 整体架构和理念不算颠覆式“新”，但在任务连通性、容错、回退机制等实现上，极度考验工程能力，远不是“换个皮”那么简单。

在 Manus 创始团队与媒体的最近一次访谈中，联合创始人季逸超提出目前 Manus 定位只是一位“通用型助手”，帮普通人把复杂工作流做完，不能完全替代用户本身。这也是因为在 ToC 场景里，普通用户对体验要求很苛刻——慢一点不行，错一点也不行，Manus 团队很清楚这一点。

如果说 ToC 用户已经够“难伺候”，那 ToB 客户对 Agent 的要求只会更高：一方面，企业希望 Agent 真正“上生产”，意味着要接入复杂的权限体系、业务系统和合规要求；另一方面，任何一次错误操作、脏数据写入、流程走错，带来的代价都远比个人用户高得多。

所以会看到，过去一年很多企业在这条路上吃了不少苦：投入人力、投入预算，最后做出来的 Agent 用不了。MIT《2025 年商业 AI 现状》报告里提到，约 95%的生成式 AI 试点项目很难进入生产环境，很多最终都卡在上线前后。

问题出在哪？就在于这些一连串的工程难题。

比如代码标准不统一、系统接口五花八门、工具调用不稳定、开发周期被拉得很长；数据资产混乱、想用调不出；安全合规和权限管理一碰就痛；甚至出现“越用越退化”的优化难题。

说到底，并不是模型不行，也不是工程师不会做，而是整个 Agent 开发还不够成熟，大家还在摸索阶段，没有提前规划一套更清晰、更稳定的“做法”。

所以，国内的云厂商开始认真思考一个问题：到底怎样才能帮助企业把 Agent 的难题解决掉？有没有一种更适合落地的开发范式？

2025 云栖大会上，阿里云 CTO 周靖人就曾提出过「AI 时代的 Agent 开发范式」。而在 1 月 7 日，阿里云百炼对“1+2+N”体系和开发范式做了一次更系统的升级，把它落成一个工程化的体系。

这套“1+2+N”体系的想法并不复杂，本质是把 Agent 落地拆成三层：

稳底座（1）：把模型和云资源这些基础能力做稳定、可扩展、可治理。地基不稳，再漂亮的 Agent 也只能停在 PoC。

定范式（2）：给企业一套把 Agent 做成“工业产品”的开发与运行体系，能开发、能部署、能迭代，交付不再反复折腾。

理杂活（N）：把真实业务里最难、最碎、但最致命的集成、权限、评测、成本这些“脏活累活”，做成可插拔的组件，让企业能按需拼装。

从这个角度看，这次阿里云百炼迭代背后体现的是一种更务实的方向：要用更工业化的方式，让企业的 Agent 在真实业务里跑起来。

一、“N”：通用大方案，不如啃硬骨头的“高手组件”

经过大量 Agent 的试错，企业如今在启动一个 Agent 项目时，最先拎出来掂量的往往不是模型，而是数据怎么处理与调用、安全问题能不能搞定、上线后怎么评估和优化。

这些硬问题不先解决，再漂亮的 Agent 构想也很难真正走进生产环境。而在阿里云百炼的“1+2+N”体系里，“N”恰恰就是优先来啃这些硬骨头的。

更关键的是，这一次“N”做了很大的升级：它把落地过程中那些最常见、最难啃、最容易反复踩坑的环节抽象出来，沉淀成一组可插拔、可组合的模块化组件。Agent 开发的难题看起来五花八门，但很多难题其实有共通的解法，可以被提炼、被复用。

“N”组件的存在，可以让企业缺什么就用什么、按需组合，把时间花在业务价值上，而不是重复造轮子。

这次升级里，一个直观的变化在应用广场：阿里云百炼把同类 Agent 做成了十多个精选合集，提供新的多模态模板，支持免登录体验，也能一键调用 API，把“试试到跑起来”的路径压得更短。

真正决定“能不能落地”的挑战，还有数据连接与知识管理、安全与权限控制、可观测与持续优化等问题。

企业做 AI 转型，数据治理永远是“卡脖子”环节。尽管大家都知道数据重要，但真落到工程上，标注、清洗以及让模型读懂私有数据的成本极其高昂。

目前，企业内部约 80%的数据以 PDF、图像、视频或会议录音等非结构化形式存在。据 IDC 预测，这些数据多处于“不可检索、不可复用”的沉睡状态。随着全球数据量预计在 2026 年激增至 221ZB，如何将这些碎片资产转化为 Agent 可调用的知识，成为企业发展的关键。

阿里云百炼的思路是把这条链路做成“工具化”：用多模态 RAG、多模态数据库、Connector 连接器，把数据处理变成更工业化的流水线。

多模态数据库通过智能解析、分类归档，打破图像/音频/视频等模态壁垒；多模态知识库 RAG 不再局限于纯文本，支持数十种格式的高精度解析，包括扫描件 PDF、复杂报表、音视频会议记录等。

在 Workflow 层面添加多模态文件处理与生成节点，同时提供覆盖 Chunking、Embedding、（多模态）Embedding、Rewrite、Retrieval、ReRank 等在内的向量化全流程能力，用于检索与消化企业数据资产。

百炼平台还提供开箱即用的 RAG 工具，企业无需自建复杂的向量库与检索链路，也能获得高性能的知识检索与生成能力。

把知识库做起来只是第一步。要让 Agent 真正有用，它就得能接入实时数据。然而，长期以来 ERP、CRM 等异构系统间的集成成本高昂，导致 65%的企业受访者认为业务系统沦为新的“数据孤岛”。

百炼平台推出的 Connector（企业级数据连接器），就是想把这个门槛降到最低。

通过 Connector，企业可以一键对接飞书、语雀、MySQL 及 OSS 存储；连上之后，这些数据既能直接喂给知识库，也能驱动工作流跑起来；平台还提供数十种预置工具（Tools），支持用自然语言直接查询或检索数据等。

当然，数据一旦接进来了，真正棘手的问题也随之出现：权限边界与责任归属难题。

长期以来，很多 Agent 在企业业务中多以匿名形式存在。这种“身份透明”导致操作链路难以溯源，不仅无法明确执行指令的主体，更埋下了越权操作的隐患。

为此，百炼平台引入 Agent Identity 组件，将 Agent 纳入企业身份治理的范畴。

通过集成 Okta、EntraID 等主流系统，平台为每个 Agent 分配数字身份，使其行为从孤立的匿名调用转变为绑定主体、可供审计的合规操作。

百炼平台也将传统的“常驻权限”升级为“按需授权”仅在执行任务时获得短期令牌，任务结束权限即刻回收。

配合权限降级机制，Agent 的边界被严格限制在用户授权范围内，确保无法越权。全链路审计日志则让每一步决策都透明可查，解决了企业“敢不敢给权限”的顾虑。

针对执行环境安全，百炼平台也构建了 Sandbox（沙盒）物理隔离屏障。当 Agent 处理外部代码或第三方数据时，系统可以利用虚拟化技术将其限制在独立空间内，精简系统调用并严控网络访问。

每一个任务会话均在“即用即弃”的容器中运行，执行完毕立即重置，彻底阻断了数据残留与交叉污染。平台同步引入实时监控与会话回放，一旦监测到异常行为将立即终止任务。这种设计为 Agent 提供了“受控下的自由”：在屏障内保持灵活性，在边界外确保系统安全。

而当 Agent 真正跑进业务之后，新的共性难题也会浮现：怎么评估、怎么持续改进。

与传统软件不同，Agent 的执行具有非确定性：即便输入相同，也可能因模型的随机性、工具调用顺序或上下文波动产生不同的输出。这导致开发者难以追踪 Agent 决策逻辑，在任务失败时无法精准定位是模型、工具还是流程缺陷。

百炼平台通过 Trace（可观测）与 Evaluate（评估）组件，实现了从“黑盒”到“透明”的转变。

Trace 组件提供完整的执行轨迹追踪，清晰复现了从思考（Thought）、行动（Action）到观察（Observation）的每一步。开发者可以判断哪一步耗时最长、哪个工具失败率最高，或是在哪个环节陷入了逻辑死循环。

结合 Token 消耗、响应速度等量化指标，这些数据可通过 Grafana 进行可视化监控，构建起实时的生产环境观测能力。

基于此，Evaluate 则建立了体系化的评价标准。

在任务完成度评价方面，百炼平台可以通过衡量目标满足率与输出质量对 Agent 进行评分；并支持“模型评测（LLMasJudge）”、专家打分与人工复查相结合的混合模式，对失败任务进行深度归因。

可以说，基于日志（Logs）、指标（Metrics）与追踪（Traces）的三大支柱，百炼平台设计了一个“评估—优化—验证”的持续迭代闭环。这种由数据驱动的迭代机制，也驱动着 Agent 实现“越用越好用”的工程闭环。

相比于自建底层架构，直接调用百炼平台的成熟组件能让开发周期缩减数倍。以 RAG 系统为例，以往搭建搜索和解析链路需要数周，现在利用多模态 RAG 组件，几个小时就能跑通。

企业不需要为每个 Agent 单独开发身份认证或数据接口，一套 Agent Identity 就能管好所有 Agent 的工号，一个 Connector 就能接通全公司的数据源。

放在阿里云百炼“1+2+N”体系中，组件化正填补模型到业务之间的最后一块拼图：模型提供计算力，开发范式定好流程，而这“N”个组件则专门负责解决数据怎么连、权限怎么划、效果怎么评、安全怎么管这些具体的“杂活”。

二、“2”：“下一代”Agent，需要新开发范式

“N”组件把坑填平，只解决了“这事能不能接得上、管得住”。企业真正要把 Agent 变成长期能用的工业生产能力，还得解决另一个现实问题：怎么开发、怎么协作、怎么迭代。

阿里云百炼“1+2+N”体系里的“2”，就负责这一点，它涵盖两种开发方式（低代码+高代码），以及配套 Agent 开发平台，通过同一套平台和运行时，分别服务两类人、两种交付方式。

为什么要做成“2”种模式？因为企业落地 Agent 的过程，基本就是两条路同时走：想快速试点、尽快看到效果，低代码更省事、更快；真要进核心业务、对接复杂系统，高代码才够灵活、够深。

更现实的是，企业在代码协作上存在长期的“割裂”：低代码不够用，高代码效率低。产品经理用低代码搭建的草案，往往需要技术团队用高代码重新开发，而这种重复劳动会导致业务逻辑在传递中失真。

为了让 Agent 更快、更深地融入业务，百炼把低代码和高代码“打通”：企业可以从低代码起步做验证，再逐步演进到高代码做优化，形成一种更自然的渐进式开发，让真正懂业务的人与懂技术的人有机协作。

据 Gartner 的预测，到 2028 年，企业里相当一部分 Agent 应用会由业务人员主导搭建。双开发模式很可能会成为 Agent 走向工业化落地的一种主流形态。

但“2”的意义还不止是“怎么写代码”。更重要的是：下一代 Agent 本身就需要新的开发范式。

过去的一年，很多企业里的 Agent 实际上还停留在比较“表层”的形态：一种是以提示词工程为核心、更多承担辅助角色的 Copilot；另一种是能处理重复流程、严格按预设步骤执行的“数字员工”。它们能提升效率，但往往缺少主动规划与闭环执行能力。

Agent 不应仅“被告知怎么做”，而是“应该主动思考怎么做”。

因此阿里云百炼提出了 Agent2.0：未来的 Agent 要能围绕目标自主规划，把复杂问题拆成可执行的小任务，过程中还能根据反馈调整策略，最后交付更稳定、质量更高的结果。

按照这个定义，Agent2.0 的核心链路是“规划—执行—反思”。

而现实里很多 Agent 开发失败，问题往往是开发范式还停留在老路上。传统那种线性链路（用户 →Agent→ 模型 → 输出）有三个硬伤：没有规划，就很难应对动态场景；没有反馈与纠错，走偏就很难拉回来；没有长期记忆，交互体验容易断裂。

为了能承载 Agent2.0 的生产级落地，百炼平台对开发范式做了系统升级：AgentScope 从过去偏“开源写代码”的工具形态，演进为覆盖 Agent 全生命周期的工业化开发平台。

第一步，是把“上手门槛”压到尽量低。

一方面，AgentScope 做了对主流模型能力的统一集成，内置 100+预训练模型，拿来就能用。

另一方面，百炼平台提供了一批可复用的智能体库，比如交易智能体（EvoTraders）、调研智能体、金融分析智能体、数据科学智能体（Data-Juicer）、浏览器使用智能体、语音智能体等，减少从零开始的成本。

第二步，是围绕更高级的 Agent2.0，把“协作与执行”能力补齐。

AgentScope 主要通过三块来支撑：

多智能体编排：引入基于 Actor 模型的分布式架构，支持多个专业 Agent 的并行协作与自动调度。研究表明，协作模式任务成功率比单一 Agent 高出 90.2%。

智能体上下文管理（长期记忆）：深度适配 Mem0、ReMe 等记忆系统。使得 Agent 能够自主存储并检索历史交互中的关键信息，在后续任务中实现能力的持续迭代。

工具调用能力：全面兼容 StreamableHTTP、SSE、STDIO 等主流接口标准。通过支持 AnthropicAgentSkill 规范，在运行时即可动态加载新工具或移除冗余资源。

在工具调用这层，ReAct 这类“边想边做”的范式，也被不少实践证明更容易形成任务闭环：学术基准测试中，ALFWorld 任务只需 2 个示例即可达到 71%的成功率，高于强化学习模型的 37%；在复杂任务中，准确率相较纯 FunctionCalling 提升约 15%–20%，成本比 CodeAct 低 78.9%。

在 Agent2.0 优化与部署阶段，阿里云百炼通过 AgentScope-Studio+AgentScope-Runtime 打通了全生命周期的工业化链路。

AgentScope-Studio 可通过自定义多维表现指标，评估工作流设计的合理性；提供从输入到输出的全链路追踪与可视化，让 Agent 行为与决策过程实现“可观测、可复盘”。

百炼平台利用评测结果持续改进，让失败样本成为训练资产，形成“评测→优化→验证→再优化”的迭代闭环，实现从“盲目调参”到“数据驱动优化”的范式转换。

在落地部署环节，AgentScope-Runtime 支持 Docker、K8S、ACK、Serverless 等多种部署形态；通过 Agent-as-a-Service 将 Agent 封装为可独立调用的 API 服务，兼容 A2A 与 ResponseAPI 等协议，便于集成、弹性扩缩与快速迭代。

如果把阿里云百炼的开发范式拆开来看，其实就是从“构建”走向“运营”的一个完整闭环。

前半段构建，重点是更快、更省力地把东西搭起来：

用可选智能体模板减少重复劳动；用多智能体编排与工作流把复杂任务拆成可协作的子任务；用高低代码一体化实现统一开发与交付；通过 ReAct 等方式完成多任务的规划、执行与自我纠偏，再结合用上下文和长期记忆支撑长链路执行等。

后半段上线运营，就是做让它智能地跑起来：

用可观测和自动化评测把效果变成可量化的指标；打通真实系统和数据源，拿到反馈并持续优化；在企业既有基础设施上实现更便捷的部署与稳定运维；同时借助 Identity、模型单元专属部署、机密推理等能力，把权限、安全与合规治理补齐。

这套开发范式的最大亮点，就是它统一按照“工业级 Agent2.0”的标准做事：高效的开发体系+可持续的反馈闭环+便捷可靠的上线部署。

三、“1”：模型优势之外，深挖“模型服务”工程

最后，无论是组件化拼装，还是低/高代码协作，最终都要落在同一个问题上：模型调用能不能稳定、能不能扛流量、能不能控成本、能不能过合规。

所以“1”是整个体系的地基——模型与云服务底座把推理服务、弹性、部署形态与安全边界做成统一供给，保证上层“能跑起来，也跑得久”。

很多企业在用 Agent 的过程中，卡住的往往不是“模型会不会”，而是一些更现实、更工程的问题：1）延迟、并发、稳定性跟不上真实业务流量；2）成本容易失控（链路长、多轮工具调用、重试一多就更明显）；3）部署和合规麻烦（私有化、混合云、权限边界、数据隔离等）。

在调用模型的时候，企业最关心的也无非就两件事：成本与性能。为此，百炼平台提供了一套云资源调度组合拳：“异步调用+闲时调度”。

以前搞大规模的数据清洗、标注，或者是分析长视频，这些任务不仅计算密集，而且耗时漫长。最头疼的就是走“同步调用”，跑到一半接口超时了，任务断掉，前面全白干。

有了异步调用就省事多了，它像寄快递一样，你把任务丢给后台，拿个任务 ID，就可以去干别的。不用在那儿死等结果，等服务器处理完了你再回来取就可以。

而“闲时调度”更像“错峰用电”：不着急的任务挪到资源空闲的时候跑，单价更划算，整体资源利用率也更高。阿里云百炼官方给出的数据是，动态调度后闲时推理成本可降低 50%。对需要处理海量数据的企业来说，这种节省是实打实的。

此外，阿里云百炼这次把“模型服务能力”也做了系统升级，主要围绕四块：模型后训练、专属模型单元部署、平台可观测、推理安全防护，系统性地”深挖“模型的服务能力。

先从选型说起。百炼平台把模型体验中心做了结构性重构，把在线模型的能力做成更直观的“能力图谱”，支持文本、视觉理解、图像/视频生成、语音交互等全模态体验。

这样企业就不用靠猜，也不用“盲选”，可以在平台上直接对比不同模型在具体场景下的表现，再做选择。

模型选定之后，是否“实用”往往取决于后训练。很多企业真正需要的不是通用能力，而是用自家数据和业务知识微调出来的“专家模型”，这才更贴近业务，也是企业的核心壁垒。

模型训完后，真正容易被“拦住”的常常是部署。自建集群运维复杂、成本也难估：为了应付峰值不得不预留一堆算力，平时又闲着浪费；多租户环境下的数据隔离和性能争抢，会让企业心里不踏实。

阿里云百炼推出“模型单元”部署，其实相当于给企业开了条“专属通道”，减少资源争抢带来的不确定性，让高并发和低延迟更稳定。

同时提供全托管的 Serverless 方式：系统会跟着实时流量自动扩缩容——忙的时候自动扩，保证体验；闲的时候自动收，尽量省成本。

官方给出的测试数据里，模型单元部署相对传统自建集群方案，推理性能提升超过 1.3 倍，并发能力提升超过 1.5 倍。对企业来说，这类提升的意义很直接：同样的业务量，成本更低性能更好。

此外，调用模型处理数据时，最难绕开的是安全——尤其在金融、医疗、法律等高敏行业。很多企业不是不想用，而是卡在一句话：数据给到模型，会不会出事？

为此，百炼平台推出模型“机密推理服务”，依托三层安全架构，为企业构建起全链路的数据保护围墙：

第一层是基于 CPU/GPU 硬件可信执行环境的机密计算能力，将模型推理运行在硬件隔离的安全区内。即便云侧其他组件遭受攻击，敏感数据也难以被窃取或泄露。

第二层是端到端加密的可信链路：实现了从用户端到云端计算中心的全程加密传输。数据在加密状态下进入 TEE 区域处理，计算结果在加密状态下返回，确保数据在“流动”与“处理”的全生命周期中始终处于保护伞下。

第三层是公开审计的可信服务：平台提供可验证的身份与安全能力证明。企业不仅能自主校验服务安全性，更能以此作为合规背书，向管理层、审计机构及客户证明其 AI 系统的高安全性。”

在使用体验上，机密推理被做成了“一键交付”的形态：企业只需要在模型库中选择支持机密推理的版本，一键部署到 TEE 隔离环境，就能直接调用机密推理服务来处理敏感数据。

放在一起看，这次升级是在原有模型性能优势之上，又补上了几块关键拼图：云资源调度、后训练、模型单元化部署、机密推理安全体系等。几块一起发力，让大模型调用变得更实用、更省钱，也更安全。

四、没人愿意再“从零开始”，阿里云百炼 Agent 平台企业版已发布

从市场角度来看，政企、金融、医疗等行业在采购云服务时，始终受困于一种不完美的平衡。

公有云上手快、性能强，但数据边界与合规要求是跨不过的门槛；私有化部署虽有安全感，但往往陷入“模型、工具、流程”极其复杂的运维战泥潭，开发周期长、技术更新慢。

1 月 7 日，阿里云百炼企业版的发布，为市场提供了一个既保留数据主权，又拥有云端顶级效率的方案。

企业版支持专有云、本地化及 VPC 隔离，百炼平台将云端的成熟能力“下沉”至企业环境。更重要的是，百炼平台企业版支持源码级交付。这不仅仅是技术开放，更是给予企业自主演进的确定性。

企业不再需要买一堆零件回去组装，而是直接获得一个在自身安全边界内运行的 Agent 基座。

事实上，企业版也并非新功能的简单集合，而是将百炼平台“1+2+N”体系（顶级模型、成熟范式、核心组件）封装为完整的交付体：

双代码统一：兼顾业务验证的敏捷性与复杂逻辑的深度定制。

多模态 RAG：激活企业沉睡的音视频与文档资产，转化为实时知识。

Trace 与 Evaluate：将 Agent 的黑盒行为拉到台面上，让调试与迭代成为标准工序。

大规模组织的管理诉求：企业版强化了多租户部署、SSO 账号集成以及细粒度的权限审计。这些功能解决了 IT 部门的核心忧虑——让 Agent 的应用在组织内部不仅“能跑通”，更“可治理”。

一个行业走向成熟的标志，是目光从技术指标移向业务价值的“深水区”。

阿里云百炼 Agent 平台企业版，本质上在扮演“AI 时代技术中台”的角色。从行业趋势上看，未来企业大概率将不会从零开始建设 AI 能力，而是直接基于一个完整、成熟的技术中台起步。

这意味着，在一年的野蛮生长后，留给企业 AI 试错的窗口期正在关闭。

展望 2026 年，Agent 应用爆发增长几乎已成共识。Gartner 预测，到 2026 年底，40%的企业应用将集成任务型 AI agents（相比 2025 年不足 5%），这也标志着 Agentic AI 正从概念走向主流生产环境。

对阿里云这样的全栈人工智能服务商而言，这将是多年技术积累转化为业务增量的红利期；对使用模型与 Agent 的企业客户而言，也将是 Agent 正式进入“拼效率、拼落地”的竞争元年。

前端生态最具影响力的开源项目之一 Tailwind CSS，正经历一场罕见的生存压力测试。

其创始人 Adam Wathan 近日在社区公开表示，由于 AI 对业务模式造成的“残酷冲击”，Tailwind 在一天之内裁掉了工程团队约 75% 的员工。

他在 1 月 7 日一期自述播客中进一步解释：在 AI 编程工具大规模采用 Tailwind、使用量持续走高的同时，这种“被默认使用”的成功并未转化为可持续的商业回报，反而持续侵蚀了团队的生存空间。若趋势不变，大约 6 个月后将无法继续支付工资。Adam 形容这是一种“非常糟糕的认知”，迫使他们必须立刻缩编，避免走到“既撑不住工资、也拿不出体面遣散”的境地。

“我真的难受。胃都拧在一起了。”Adam 说。

“因为这件事，我感觉自己像个失败者：我做出了一个几乎‘统治世界’的开源 CSS 框架，用的人越来越多、越来越火，但商业上的成功，却和开源的成功呈现出一种反向关系。”

“我们只剩下六个月了。”

“我现在的每一秒，都必须用来让公司活下去”

这场裁员风波最终被外界注意到，触发点是一则围绕“大模型（LLM）文档支持”的 GitHub Pull Request。

2025 年 11 月，社区开发者向 Tailwind 官方仓库提交了一项合并请求，要求新增一个 llms.txt 端点，用于提供面向 LLM 优化的 Tailwind CSS 全部文档的纯文本合并版本。以此希望在所有文档页面加一个“复制为 Markdown”的按钮，因为现在很多人会把文档内容直接喂给 AI。

从描述来看，这个 PR 是将 Tailwind 所有官方文档（共 185 个文件）在构建阶段静态合并为一个纯文本、无 JSX、按章节顺序排列的文档文件，方便 LLM 直接读取和使用。从工程实现上看，这只是一个构建期脚本，改动规模有限。

但该 PR 提交后长期未获推进。面对社区的追问，Tailwind 创始人 Adam Wathan 回应称，当前团队有更重要的事情要做，比如先想清楚怎么让公司赚到足够的钱、把业务维持下去。他直言，如果越来越多的人不再访问文档，而是直接依赖 LLM 去爬 Markdown 文件，“只会导致文档访问量进一步下降，也就意味着更少的人会了解到我们的付费产品，最终让业务变得更加不可持续。”

“很抱歉，我现在没有时间去做那些不能帮我们付账单的事情。”

Adam 关闭了这个 PR。当然，评论区立刻炸了：这对社区太糟糕了，你们只想着赚钱，太失望了......

有社区开发者认为，让软件更容易融入用户工作流、解决他们日常互动中的痛点，本身就是扩大潜在付费用户的关键前提；而此功能旨在让人们能够使用 Tailwind 更快、更高效地构建更多内容，现在 Adam 以“变现”为由拒绝此类功能，“等于是在告诉你的客户，从他们那里赚钱比为他们提供服务更重要。”

争议升级后，Adam 不得不再次回应，并披露了 Tailwind 的真实处境。

他坦言他知道这个功能的价值，但现实情况是：“就在昨天，我们工程团队里有 75% 的人失去了工作，这是 AI 对我们造成的残酷冲击。”

在这样的背景下，他坦率地说，自己已经很难再把时间投入到这类“不直接带来收入”的事情上：“我现在的每一秒，都必须用来让公司活下去。确保还留在这里的人，每个月都能拿到工资。”

他同时透露，尽管 Tailwind “比以往任何时候都更受欢迎”，但 “我们的文档流量相比 2023 年初已经下滑了大约 40%。”而文档是他们的唯一分发渠道，没有客户，就意味着 “我们根本负担不起继续维护这个框架。”

更残酷的是，虽然 Tailwind “增长速度比历史上任何时候都更快，规模也比任何时候都更大”，但 “收入却下滑了接近 80%。”他总结说，眼下 “让 Tailwind 变得更好用”，与 “让这个框架的开发在商业上变得可持续” 之间，“几乎已经看不到任何相关性。”

所以，他必须先解决生存问题，不然“一旦没人继续维护，这个项目最终会变成无人问津的弃置软件。”

更反直觉的现实：Tailwind 反而“到处都在被用”

这件事迅速在 Hacker News 上爆了。

HN 首页一条帖子标题很直接：“Tailwind 的创作者裁掉了 75% 的工程团队”，链接指向 TailwindLabs 的 GitHub 讨论。发出约 10 小时后，评论也堆到 598 条，迅速变成当天的高热讨论。

这场裁员之所以在社区引发震动，很大程度上来自一种强烈的反差感。

2020 年 7 月，Adam Wathan 还在公开回顾 Tailwind 的“上升期叙事”：Tailwind 的累计安装量刚刚突破 1000 万，而他们的首个商业化产品 Tailwind UI 上线仅约 5 个月，收入就即将跨过 200 万美元。他把这段经历形容为“完全超出想象”，并特意把最初发布在 Twitter 的长帖重新整理成文章。

而且在 AI 的世界里，在大多数开发者的体感里，Tailwind 也不是处在衰退期，恰恰相反，它正在悄然变成一种 AI 生成 UI 的“默认选项”。当人们打开 AI 编程工具，让模型生成一个页面、一个组件，甚至一整套 UI 时，模型往往不会再询问“要不要写 CSS”，而是直接给出一串熟悉的 class——这种选择并非出于偏好，而是因为在当下的工程环境里，这样做最快、最稳，也最不容易出错。

Glide CEO 兼创始人 David Siegel 认为：“你可以把 Tailwind 看成是一套无代码（no-code）工具包，它实际上让 AI 在设计这件事上变得更强了。”

有意思的是，AI 在使用 Tailwind 这件事上，确实表现得异常出色。就像无代码平台通过预制组件，帮助非开发者也能构建稳定、设计良好的应用一样，AI 也开始把 Tailwind 当作一套“组件库”来使用——这让它能够更快工作，并生成更可靠、更一致的样式结果。

“AI 并不是在 CSS 这种底层样式语言上变得更强了，”Siegel 解释道，“而是我们发明了一种 AI 更擅长使用的‘高层语言’，它叫 Tailwind。”他进一步指出：“它看起来几乎就像自然语言。你不用写一堆括号、冒号之类的东西，只需要写 text-black，文本就变成黑色；写 rounded-md，按钮就会变成中等圆角。这些组件库，本质上就是建立在设计之上的低代码 / 无代码抽象。”

现代 AI 编程助手最擅长的，往往是遵循清晰、可重复的模式，或者在一个定义良好的词汇体系中进行组合与生成。而 Tailwind 的方法论恰好满足了这一点：它提供了一套高度一致的 class 命名和样式模式，使 AI 更容易生成正确、相关且稳定的代码建议。

正如Vercel CEO Guillermo Rauch所说：“整个 Web 生态正在向 Tailwind 标准化，所以每个 AI 工具都在用它。”

“我们只剩下六个月了”

在 Adam Wathan 看来，AI 一把极其锋利的双刃剑。

“我认为，AI 是我们业务陷入困境的重要原因之一——即便它也让 Tailwind 变得比以往任何时候都更受欢迎。但同时，我也觉得 AI 是一项了不起的技术，我对它感到兴奋，也在思考它如何帮助我、帮助我们。在目前这个阶段，我们可能被迫要更认真地思考，如何利用 AI 来覆盖我们需要处理的所有事情。”

在 1 月 7 日发布的音频中，Adam 反复提到一个他此前一直试图回避、却最终不得不正视的事实：公司的收入已经连续多年处在下滑通道，而且还在继续下滑。

过去几年，这种下滑并不剧烈，甚至“慢到让人几乎察觉不到”。每个月的收入只是比上个月少一点点，账单依然能付，团队还能维持运转，久而久之，这种“更低但还能接受的收入水平”就变成了新的常态。

Adam 形容，这是一种典型的“温水煮青蛙”状态。

真正的转折点，发生在最近的假期里。他第一次不再凭感觉判断，而是认真做了一次收入预测：拉数据、画曲线、计算每个月的平均下降额。结论比他预期得要糟糕得多：收入并没有触底企稳，而是以几乎固定的绝对值持续下滑——这意味着，从比例上看，下滑速度只会越来越快。如果假设什么都不改变，那么大约6 个月之后，公司就将无法继续支付工资。

对一家小型团队来说，6 个月并不算长。如果继续拖下去，等到现金流真正断裂，团队不仅保不住，甚至连体面的遣散都无法提供。相比之下，现在主动缩编，至少还能给被裁的同事留出缓冲期，让他们有时间寻找下一份工作。

于是，在本周一，Tailwind Labs 正式裁掉了工程团队的 75%。

公司规模并不大，“75%”对应的其实是3 个人。但 Adam 特意强调比例的意义：如果只说“裁了 3 个人”，听起来像是小幅调整；而现实是，工程团队原本只有 4 名工程师，如今只剩1 人。这对团队而言是一次结构性的变化。

裁员之后，Tailwind 的资源配置也被压缩到了极限：

现在的团队结构是这样的：剩下的核心成员是三位公司合伙人——我自己、因 Refactoring UI 而为人熟知的 Steve（一直负责设计），以及 Jonathan Rennick（最早和我一起创建 Tailwind，也做了 Inertia.js）。

 

除此之外，我们只有一名全职工程师 Robin——他从零开始做了 Headless UI，也从零做了 Tailwind 3 和 Tailwind 4，是在公司待得最久的人。

 

还有 Peter，他更多是兼职，负责合作伙伴计划、一些运营事务和客户支持。

 

就这些人了。

换句话说，整个公司只剩下“3 位合伙人 + 2 名员工”，“这就是我们接下来全部的资源”。

接下来，Adam 也将重新回到更偏 IC（个人贡献者）的角色。他承认这算是某种“银边”：随着团队变大，他的工作越来越偏高层和战略层，关注哪些事情需要完成，并分配给合适的人，而不是亲自构建；而现在，团队规模逼迫他必须亲自下场。

被裁的三位工程师，都是他非常欣赏、也非常享受共事的人：Philip既能啃 Tailwind 核心，也能把 Tailwind Plus 的 elements 组件库和组件预览的复杂前端界面硬生生推进落地；Jordan是团队的“疑难杂症终结者”，最擅长扎进陌生代码库定位上游/兼容性问题、快速开 PR 修复，同时也能在 Headless UI 与服务器排障上扛住关键战役；Dan则以设计工程师身份主导 Tailwind 4 的视觉与品牌更新，设计 P3 色彩体系并自研选色与预览工具，还贡献了大量高质量的图解与课程平台素材。

他原本对未来和他们一起继续做新东西充满期待，脑子里有很多计划，很多想一起推进的方向。但现实摆在面前，只剩下两个选择：要么让他们在这里“免费工作”，要么放他们离开，去一个真的能每个月按时发工资的地方。

他选择了后者。“我真的很难受，”Adam 说，“胃都拧在一起了。”

而且他也意识到，外界并不总能理解裁员背后的现实逻辑。在社交平台上，总有人会把裁员简单归因为贪婪、冷血，或者“不在乎社区”。作为创始人，这几乎是一种默认要承受的角色负担——你很容易被塑造成反派。

“不是因为我贪婪、想赚更多钱，而是因为收入正在逼近零点，而我刚刚裁掉了我这辈子见过最优秀的三位工程师之一。我不想事情变得更糟。”

“说实话，我甚至把 tailwindcss.com 的仓库暂时设成了私有，只是不想再面对 issues 和 PR。睡了一觉之后，我可能会撤回这个决定。但我会反复动摇，本身就说明我这周的情绪状态真的不太对。”

“现在，开源项目越受欢迎，生意反而越艰难。这真的很残酷。这就是现状。”

参考链接：

https://news.ycombinator.com/item?id=46527950

https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957

https://adams-morning-walk.transistor.fm/episodes/we-had-six-months-left

为了提高其软件系统的合规覆盖率，Meta 已经将大型语言模型应用于变异测试。这种方法将 LLM 生成的变异体（mutants）和测试集成到 Meta 的自动化合规加固（ACH）系统中，消除了传统变异测试在可扩展性和准确性方面的限制。该系统的目标是在满足合规义务的同时保持产品和服务的安全，帮助团队更高效地满足全球监管要求。

变异测试是故意在代码中引入一些小的变异体，并检查测试是否能够检测到它们，以此来评估测试套件的有效性。由于变异体数量过多、计算成本高昂且存在价值有限的等效变异体等因素，传统编译测试的应用有限。Meta 的方法是利用大型语言模型生成具备上下文感知能力的变异体以及对应的测试，从而降低噪声并使工程工作聚焦于高价值代码路径。

在没有 LLM 指引之前，变异测试依赖于基于规则的静态操作符。这些操作符会无差别地生成大量的变异体，其中许多在语义上与原始代码等价，压跨了测试基础设施和开发流程。

Meta的ACH系统使用 LLM 生成恰当的变异体和有针对性的测试，重点关注隐私、安全和监管问题。基于LLM的等价检测器会过滤掉多余的变异体，而测试生成器会生成单元测试，工程师可以进行审查但不需要手动编写，这显著降低了运营开销。Facebook、Instagram、WhatsApp 和 Meta 的可穿戴平台的早期部署产生了数万个变异体和数百个可执行的测试。

ACH 系统架构概览（图片来源：Meta技术博客）

自从将研究成果纳入 ACH 以来，Meta 在FSE 2025和EuroSTAR 2025大会上展示了他们的工作成果，即 LLM 如何帮助他们克服以前限制大规模变异测试的障碍。借助生成式 AI 更高效地生成测试用例，传统上用于评估测试质量的变异测试如今变得更具实用性和可扩展性。

正如 Meta 工程团队所强调的那样：

从 2024 年 10 月到 12 月，我们尝试在 Facebook、Instagram、WhatsApp 和 Meta 的可穿戴平台上部署了用于隐私测试的 ACH。在数千个变异体和生成的数百个测试中，隐私工程师接受了 73%的测试，其中 36%被判定为与隐私相关。

在 ACH 的基础上，Meta 推出了即时捕获测试（JiTTest）挑战赛，旨在探索大型语言模型在自动化软件测试中的应用。该系统会生成强化测试以防止回归问题，并生成捕获测试用于检测新代码或变更代码中的缺陷。它会在拉取请求进入生产环境前生成测试结果以供审核，这既解决了测试预言问题（Test Oracle Problem），又保留了人工监督环节。在 FSE 2025 大会上，Meta 发表了一篇论文，详细阐述了 JiTTest 挑战及其相关的开放研究课题。

Meta 表示，LLM 将耗时且容易出错的过程转变为更高效的系统，帮助简化并优化了合规和风险管理框架。正在进行的工作包括：将 ACH 扩展到隐私测试和 Kotlin 之外的更多领域和语言；通过微调和提示工程改进变异体生成；解决测试预言问题。Meta 还在研究开发人员如何与 LLM 生成的测试互动，以提升采用率和可用性。更多研究成果将在即将召开的会议中展示，包括Product@Scale。

https://www.infoq.com/news/2026/01/meta-llm-mutation-testing/

闫俊杰在商汤敲钟前夕离开，创立了 MiniMax（上海希宇科技），也造就了全球从创立到 IPO 用时最短的 AI 企业——4 年，进程明显快于行业常态。

就在刚刚，1 月 9 日，MiniMax紧随其后挂牌上市，股票代码 00100。招股书显示，MiniMax 的 ToC 收入已经反超 ToB，这在中国大模型公司中极为罕见。

其招股书还透露了一堆硬核数据，截至 2025 年 9 月 30 日：

• 累计个人用户：超过 2 亿

• 覆盖 200+国家和地区

• AI 原生产品 MAU：约 2760 万

• 企业与开发者客户：超过 10 万家

在这次 IPO 中，Mini Max 计划发行约 2540 万股 H 股，开盘价 235.4 港元，截至上午 10:30，股价已飙升超 60%，市值超 820 亿港元（约合人民币 738 亿元）。

据富途证券数据，MiniMax 此次 IPO 超级火爆，公开发售部分的超额认购倍数高达 1209 倍，投资者通过保证金方式认购的金额累计超过 2533 亿港元。

资本市场为 MiniMax 的技术野心“买单”

在国内近年来涌现的一批 AI 独角兽中，唯二高频更新技术论文、投资开发者生态的，是 MiniMax 和 DeepSeek 背后的深度求索。

闫俊杰曾在各种场合明确表达： MiniMax 是一家技术驱动的公司。据招股书显示，MiniMax 最大的成本就是研发成本，为了在基础模型技术上集中注意力，海外版 App 甚至没有第一时间做英文化。投资人的评价大体也能回归到技术要素，即闫俊杰是一个真正对 AGI 有信仰的人，“他很真”。

这是除市场数据外，MiniMax 市值最明确的支点。

仅在 2025 年，MiniMax 已通过至少两篇公开科研论文系统阐述其大模型架构与推理优化方案，其核心成果包括 MiniMax-01，即基于 Lightning Attention 与 MoE 的超长上下文大模型；以及 MiniMax-M1，即针对推理计算效率进一步优化的模型版本。

相关论文不仅披露了核心机制，还在处理百万级 token 上下文和推理效率上提出可复现技术路径，而非简单参数展示。

回到 2024 年初，在稠密模型仍占主流的背景下，MiniMax 率先推出了中国首个混合专家系统（MoE）大模型 abab6——比 DeepSeek 火出圈 R1 早了约一整年。

在行业仍普遍依赖 Softmax Attention、并为其二次计算复杂度付出高昂算力成本时，MiniMax 开始在模型中大量引入自研的 Lightning Attention（线性注意力）。

具体做法，简单来说就是在每 8 层模型结构中，只保留 1 层传统注意力，其余 7 层改用线性注意力，从而把长上下文推理的计算压力“削薄”。

改动后的直接效果是：模型在面对超长文本、长代码或多轮复杂推理时，不再随着上下文变长而指数级变慢。

这套注意力设计与 MoE 架构叠加后，进一步放大了效率优势，使模型在保持推理能力的前提下，大幅提升了长文本、长代码和复杂任务场景下的计算效率。

相比智谱以 GLM 系列基座模型为核心，在 ToB 与 ToG 侧已跑出较为稳健盈利能力的路径；MiniMax 展现出的是另一种取向：模型更强调产业化落地，已在 ToC 端取得了不错的成果。

围绕自研大模型，MiniMax 已形成包括 MiniMax Agent、海螺 AI、MiniMax 语音、星野以及开放平台在内的产品矩阵。

同时在海外市场亦已有实质进展：其产品和服务已覆盖 200 多个国家和地区，累计触达超过 2.12 亿名个人用户，并服务超过 13 万家海外企业与开发者（包括订阅、API 调用等渠道）。

按 2024 年基于模型的收入计算，MiniMax 是全球第四大 pure-play 大模型技术公司，还是全球第十大大模型公司，覆盖文本、视觉、音频、视频的全模态模型体系。

在上市前的近一年内，MiniMax 完成了从 MoE 架构探索（abab 6 / 6.5）到基础大模型开源（MiniMax-01），再到高级推理模型（MiniMax-M1）的连续迭代。

以 MiniMax-01 系列为例，模型总参数规模已达数千亿量级，但单个 token 实际参与计算的参数仅为几十亿，使得模型可以在控制成本的前提下，原生支持百万级乃至更长的上下文窗口。

在 2025 年 12 月 23 日，MiniMax 还对外发布了最新旗舰级 Coding & Agent 模型 M2.1。

在衡量多语言软件工程能力的 Multi-SWE-bench 测试中，该模型在仅约 10B 激活参数的前提下取得 49.4%的成绩，超越了 Claude Sonnet 4.5 等国际顶尖竞品，拿下全球 SOTA。

M2.1 要补上的，是此前不少模型在工程能力上的短板——过去的模型在编写简单脚本或前端代码时尚可应付，但一旦进入后端工程、系统架构或底层逻辑层面，表现往往迅速失稳。

这个模型的关键变化在于，其能力边界首次延伸至更完整的后端开发规范。

这些技术实现背后，是一支极其年轻的团队。据每日经济新闻消息，截至 2025 年 9 月底，MiniMax 员工 385 人，平均年龄 29 岁，研发人员占比近 74%，董事会平均年龄 32 岁。

其核心团队由一批来自商汤科技、全球一流高校和顶级科研机构的技术骨干组成，以创始人闫俊杰为首，包括杨斌、周彧聪等联合创始人。

闫俊杰拥有东南大学、本科到中科院自动化所博士及清华博士后背景，曾担任商汤副总裁与研究院副院长。

杨斌具备加拿大博士及 Uber ATG 与国际初创工程经验；周彧聪则是商汤早期算法团队核心成员。

团队多数来自 AI 与深度学习前沿领域，在 NLP、语音、视觉、生成模型等方向拥有丰富经验和多项全球发明专利。

站在年轻团队另一面的，是 AI 投资界的“老炮”们。

早期有阿里、腾讯、红杉中国、高瓴、IDG、云启、米哈游等产业与风投参与；IPO 前夕，阿布扎比投资局、Mirae Asset、Aspex、易方达等长线机构接力。

尤其是阿里，持有的 MiniMax 股权占比还要大于在智谱的比重。连续两场 IPO 后，一场投资界和 AI 创业团队之间的化学反应和默契已经诞生。

上市之后，还需直面 Claude Code 等问题

需要指出的是，由商汤的 ToB/ToG 模式，转到如今的 ToC/ToB 模式，闫俊杰麾下的 MiniMax 还未实现整理盈利；至少想赢得全球 AICoding 市场，绕不开和 Claude Code 的直接竞争。

Claude Code 是一个面向真实软件工程的 Coding / Agent 模型，由 Anthropic 公司推出。该模型的重点是在 AI 生成代码以外，确保模型在工程约束下不失控，堪称 AICoding 神器。近日， Anthropic 宣布，Claude Code 上线仅 6 个月，已经创造了近 10 亿美元年化营收。

从公开信息看，MiniMax 并没有试图直接复刻 Claude Code 的路径，而是选择了另一种更偏效率驱动的技术路线。

MiniMax 在 Lightning Attention + MoE上的投入，本质上是在解决一个问题：如何在成本可控的前提下，把上下文和工程复杂度拉到“真实软件世界”的尺度。

对于 Coding 模型来说，长上下文不是加分项，而是入场券。 没有足够高效的注意力结构，就无法在真实代码库上长期运行 Agent。

M2.1 针对 Multi-SWE-bench 的表现，某种程度上正是在回应 Claude Code 的“主战场”——不是写某一段代码，而是完成跨语言、跨模块、带验证的软件工程任务。

这意味着 MiniMax 正在补的，并不是单点能力，而是：后端规范、工程一致性，和多语言协作能力，这正是 Claude Code 最难被替代的部分。

MiniMax 若想在全球市场正面竞争，最终比拼的也不会只是 Benchmark，而是 Agent 是否可控、错误是否可解释，以及是否敢被放进 CI / CD 流程。

从招股书来看，MiniMax 的研发投入在过去三年中持续攀升：

2022 年为 1060 万美元，2023 年增至 7000 万美元，2024 年进一步扩大至 1.89 亿美元；截至 2024 年及 2025 年 9 月 30 日止的九个月，研发开支分别达到 1.387 亿美元和 1.803 亿美元。相关投入主要用于模型训练过程中产生的云服务费用。

另外，在头部云厂商和海外独角兽的夹击之下，MiniMax 同时承受着 ToB 与 ToC 两个市场的竞争压力。

模型技术仍在快速演进，这场拼性能、拼效率、拼工程化的技术马拉松还在继续；上市，只是把比赛带入了下一个赛段。

在一次采访中，闫俊杰提到，MiniMax 确实放弃过一些 ToB 订单，是基于对自身交付能力的判断，避免分散注意力。那么，如果 ToB 领域的工程化交付，当下还不是 MiniMax 的“长板”，短期来看，就只剩“技术登顶”一条路能帮 MiniMax 走到终局。

闫俊杰说他在 Dota2 游戏里爱玩小精灵，因为这个英雄实现过从五号位（辅助）转型成为一号位（核心），最终主宰比赛。

目前看来，对于 MiniMax 而言情况类似，能否在 Benchmark 上五转一，保持模型能力长期领先，是上市后走向 AGI 的关键。

参考链接：

https://www1.hkexnews.hk/listedco/listconews/sehk/2025/1231/2025123100026_c.pdf

https://huggingface.co/MiniMaxAI/MiniMax-M2.1?utm_source

Facebook 2025年Python类型调查在 1200 多名受访者中进行，重点介绍了 Python 开发人员如何以及为什么越来越多地采用该语言的类型提示系统。该调查还揭示了开发者最看重的东西，以及他们最大的挫折和愿望。

总体而言，86%的受访者表示他们“总是”或“经常”在代码中使用类型提示，其中具有 5-10 年 Python 经验的开发人员的采用率最高。

虽然数据显示，类型提示在被调查的样本中被广泛采用，但不排除选择偏差，因为使用类型提示的开发人员可能更有可能做出回应。尽管如此，该调查揭示了使用类型提示的 Python 开发人员的一些有趣趋势。

调查结果显示，Python 的类型提示系统已经成为大多数工程师开发的核心部分。[...]我们发现，所有经验水平的玩家对打字的接受程度都是相似的，但也存在一些有趣的细微差别。

初级（0-2 年经验）和高级（10 年以上经验）开发人员使用类型提示的频率都较低，分别为 83%和 80%。该调查的作者认为，初级开发人员面临更陡峭的学习曲线，而高级开发人员可能正在处理大型遗留代码库，而在这些代码库中采用类型提示更为困难。

开发人员列举了采用 Python 类型系统的几个好处，包括更好的可读性和代码内文档，改进的 IDE 和工具支持，早期的错误检测以及增强的信心。他们还强调了高级特性的价值，如协议、泛型和在运行时检查注释的能力。

另一方面，受访者指出了一些挑战，包括第三方库中有限的类型提示支持，泛型和修饰符等高级特性的复杂性，以及复杂类型的冗长性增加。其他痛点包括工具碎片化、缺乏运行时强制执行以及难以修改遗留代码。受访者还指出，Python 的类型系统似乎不如其他语言（如 TypeScript）的表达能力强，而且它的快速发展意味着语法和最佳实践在不断变化。

调查中另一组有趣的发现涉及改进 Python 类型系统的方法。一些建议包括借鉴 TypeScript 的特性，如交叉类型、映射和条件类型、实用程序类型（如Pick、Omit、keyof和typeof），以及更好的字典结构类型。其他建议侧重于更好地支持泛型和代数数据类型，包括更高级的类型；基于类型提示的可选运行时类型强制和性能优化；改进了对函数包装器和装饰器等模式的处理，支持动态属性；等等。

在工具方面，MyPy 仍然是首选的类型检查器，采用率为 58%，紧随其后的是 Pyright/Pylance。新的基于 Rust 的类型检查器（如 Pyrefly、Ty 和 Zuban）越来越受欢迎，被超过 20%的受访者使用。Visual Studio Code 是最常见的 IDE，其次是 PyCharm 和 Vim/Neovim。

这项调查中还有更多内容无法在此一一介绍。请务必阅读原始文章以获取全部详细信息。

https://www.infoq.com/news/2026/01/facebook-typed-python-survey/