面条的草稿箱

无原创，纯转发

面条的草稿箱

  1. 面条的草稿箱

    AgentFS：为 AI Agent 设计的“可审计”文件系统AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统：不仅能像传统文件系统一样读写文件/目录，还把 Agent 的状态与行为记录成可查询、可快照的结构化数据，便于调试与复盘

    AgentFS：为 AI Agent 设计的“可审计”文件系统

    AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统：不仅能像传统文件系统一样读写文件/目录，还把 Agent 的状态与行为记录成可查询、可快照的结构化数据，便于调试与复盘。

    它解决什么问题？

    • 可审计：每一次文件操作、工具调用、状态变更都会写入同一个 SQLite 数据库，可直接用 SQL 追踪“发生了什么”。
    • 可复现：一个 .db 文件就是完整运行态，支持复制/快照/回滚，用来复现某次执行或做 what-if 实验。
    • 可迁移：所有内容都封装在单个 SQLite 文件里，易于移动、备份，甚至纳入版本管理。

    包含哪些组件？

    • SDK：TypeScript / Python / Rust（程序化访问文件系统、KV、工具调用记录）。
    • CLI：初始化与管理 AgentFS；在 Linux 用 FUSE、macOS 用 NFS 挂载到本机目录；也可在沙箱里把它挂载到 /agent。
    • 规范：提供基于 SQLite 的 Agent 文件系统规格（SPEC）。

    使用提醒

    • 官方标注为 ALPHA 阶段：更适合开发、测试与实验环境，关键数据请谨慎上生产。

    原链接：https://github.com/tursodatabase/agentfs
    #AI代理 #文件系统 #SQLite #可审计 #开发工具
    GitHub
    GitHub - tursodatabase/agentfs: The filesystem for agents.
    GitHub - tursodatabase/agentfs: The filesystem for agents.
    The filesystem for agents. Contribute to tursodatabase/agentfs development by creating an account on GitHub.

    AI代理文件系统SQLite可审计开发工具

  2. 面条的草稿箱

    CoreSpeed：为 AI Agent 打造的容器运行时基础设施CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验

    CoreSpeed：为 AI Agent 打造的容器运行时基础设施

    CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验。

    它解决的核心问题：把 Agent 从 Demo 变成可上线的系统。

    关键能力一览

    • 127ms 级别快速启动：通过内置 Warm Pool，让容器接近“秒开/毫秒开”，减少冷启动等待。
    • 按用户隔离的安全沙箱：一人一容器，降低数据串扰与安全风险。
    • 无限水平扩展 + 可缩到 0：按需分配资源，空闲可降到零成本运行。
    • AI & MCP Gateway：统一接入 AI 模型与 MCP Server，提供可观测性与安全防护（例如减少 API Key 泄露风险），并支持按调用计费。

    配套：Zypher（TypeScript Agent Runtime）

    同时他们提供 Zypher SDK，强调：

    • 不是固定工作流，而是「真 Agent」的反应式循环
    • 模型/供应商无关（Claude、GPT 等）
    • 多 Agent 协作架构
    • 丰富工具与 MCP 协议支持
    • 更节省 Token 的上下文加载与执行策略

    原文链接：https://www.corespeed.io/

    #AI代理 #容器基础设施 #MCP #AgentRuntime #开发者工具
    CoreSpeed
    CoreSpeed — Everything your agents need.
    CoreSpeed — Everything your agents need.
    One MCP endpoint that gives any agent — Claude Code, Codex, Cursor — your apps, your team's memory, and built-in tools, with spend caps and an activity log.

    AI代理容器基础设施MCPAgentRuntime开发者工具

  3. 面条的草稿箱

    Amp 宣布下线 Amp Tab：Tab 补全时代正在退场Amp 团队宣布将移除 Amp Tab（内联 Tab 补全功能），理由很直接：这不再符合他们看到的未来

    Amp 宣布下线 Amp Tab：Tab 补全时代正在退场

    Amp 团队宣布将移除 Amp Tab（内联 Tab 补全功能），理由很直接：这不再符合他们看到的未来。

    他们的判断基于一个变化——AI 写代码的占比正在迅速上升：

    • 一年前，代码大多还是人手写
    • 2025 年 6 月发布 Amp Tab 时，Amp 已经在写大部分代码
    • 现在，Amp 负责了他们 90% 的交付代码

    Amp 认为，Tab 补全与传统补全引擎来自“人写为主、AI 辅助”的时代；但这个时代正在结束。越来越多用户的工作方式变成：几天不打开编辑器，也能持续交付代码。瓶颈不再是“写得快不快”，而是“把代码产出、落地得快不快”。

    因此，Amp 将把资源投入到“后补全时代”的方向：默认由智能体（agents）完成大部分编码工作，而不是在输入时做局部补全。

    时间安排：

    • Amp Tab 将继续可用至 2026 年 1 月底
    • 之后如果仍需要内联补全，可考虑：Cursor / GitHub Copilot / Zed

    原文链接：https://ampcode.com/news/tab-tab-dead

    #AI编程 #代码补全 #开发者工具 #智能体 #Amp
    Ampcode
    Tab, Tab, Dead
    Tab, Tab, Dead
    We're removing Amp Tab. It is not part of the future we see.

    AI编程代码补全开发者工具智能体Amp

  4. 面条的草稿箱

    以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策

    以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化：从最初“有些提示能一次跑通就很惊喜”，到现在“默认就该一次跑通”。在这种前提下，他甚至不再逐行读代码，而是看执行/修改流，关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法：

    • 先从 CLI 做起：任何产品先做命令行版本，方便代理直接运行验证，形成闭环；核心逻辑稳了再上 UI（比如扩展、App）。
    • 关键决策是生态与依赖：语言/框架/依赖选对了，代理更容易一次完成；作者常用 TypeScript（Web）、Go（CLI）、Swift（macOS/iOS）。
    • 更偏向“对话式协作”，而不是复杂流程：先和模型聊清楚、让它探索代码、共创方案，满意后再让它开干；他认为“Plan mode”更像旧时代不得已的手段。
    • 对比 codex 与 Opus：codex 常会先长时间读代码再动手，虽然更慢但更稳，尤其适合大型功能和重构；Opus 更“急”，适合小改动但更容易漏上下文。
    • 迭代式构建，不依赖回滚：不喜欢 checkpoint/频繁 revert，更多是让模型继续改、继续朝更好的方向“绕山而上”。
    • 自动化与多项目并行：同时推进多个项目，用队列把想法排进去；瓶颈往往是人而不是编排系统。
    • 配置思路：提高工具输出 token 上限、合理设置自动压缩阈值，让模型能一次读更多文件；作者强调新压缩机制更可靠，甚至像一次“复查”。

    如果用一句话总结：当“写代码”越来越像可并行外包给代理的体力活，工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上；而真正影响交付速度的，往往是推理等待时间和你是否想清楚要做什么。

    原链接：https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程
    Peter Steinberger
    Shipping at Inference-Speed | Peter Steinberger
    Shipping at Inference-Speed | Peter Steinberger
    Why I stopped reading code and started watching it stream by.

    AI编程Codex开发工作流效率工具软件工程

  5. 面条的草稿箱

    Repogrep：更快地在 GitHub 代码库里找答案Repogrep 是一款主打“超快速代码库搜索”的 AI 工具，可在任意公开的 GitHub 仓库中进行检索

    Repogrep：更快地在 GitHub 代码库里找答案

    Repogrep 是一款主打“超快速代码库搜索”的 AI 工具，可在任意公开的 GitHub 仓库中进行检索。你可以直接粘贴仓库链接，或通过关键词搜索，快速定位代码、项目与相关信息。

    适合的使用场景包括：

    • 初次接手项目时，快速摸清结构与关键模块
    • 排查问题时，跨仓库定位相同实现或调用链
    • 做技术调研时，对比不同项目的实现方式

    原链接：https://app.ami.dev/repogrep

    #代码搜索 #GitHub #开发工具 #AI助手

    代码搜索GitHub开发工具AI助手

  6. 面条的草稿箱

    Open Responses：让 LLM 接口真正“可互通”的开放规范Open Responses 是一个开源规范与生态，目标是基于 OpenAI Responses API 的理念，建立多模型提供方可互操作的统一接口层

    Open Responses：让 LLM 接口真正“可互通”的开放规范

    Open Responses 是一个开源规范与生态，目标是基于 OpenAI Responses API 的理念，建立多模型提供方可互操作的统一接口层。它通过共享 Schema 和配套工具，让开发者能用同一种请求/输出结构，跨不同提供方调用模型、处理流式返回，并组合更复杂的 Agent 工作流。

    为什么需要它？
    现在各家 LLM API 的核心组件越来越相似（消息、工具调用、流式、多模态等），但细节编码方式不同，迁移与兼容成本高。Open Responses 希望把“共同部分”沉淀成稳定规范，减少重复适配。

    它强调的设计方向：

    • 默认多提供方：一套 Schema 映射多家模型/平台
    • 更贴近真实 Agent 工作流：统一的流式事件、工具调用模式，以及以“items”作为输出与工具使用的原子单元
    • 可扩展但不碎片化：核心稳定，同时允许在必要时容纳提供方特性

    如何开始：

    • 阅读规范，理解 items、流式事件、工具使用等核心概念
    • 查看 OpenAPI 参考，掌握完整类型与接口面
    • 用官方的验收测试验证你的 API 实现一致性

    原链接：https://www.openresponses.org/

    #LLM #开放规范 #多模型 #互操作 #API设计
    www.openresponses.org
    Open Responses
    Open Responses documentation overview.

    LLM开放规范多模型互操作API设计

  7. 面条的草稿箱

    Tool Search Tool：让大规模工具库“按需加载”当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具

    Tool Search Tool：让大规模工具库“按需加载”

    当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具。Tool Search Tool 的思路是：先只暴露“搜索工具的工具”，其余工具标记为延迟加载；模型需要时先搜索，再把最相关的少量工具定义加载进来使用。

    核心机制（7 步）

    • 请求里先放入工具搜索工具（Regex 或 BM25 版本）+ 少量常用非延迟工具
    • 其余工具定义加上 defer_loading: true（不立即进上下文）
    • 模型需要更多工具时，先调用 tool search
    • 服务端返回 3–5 个最相关的 tool_reference
    • 这些引用会被自动展开成完整工具定义
    • 模型再从“已发现”的工具里选择并调用
    • 这样既省上下文，又保持工具选择准确率

    两种搜索方式怎么选

    • Regex 版（tool_search_tool_regex_20251119）：查询是 Python 正则，不是自然语言；适合你希望可控匹配（如 get_.*_data、(?i)slack）。限制：模式最长 200 字符。
    • BM25 版（tool_search_tool_bm25_20251119）：查询用自然语言；更适合“我想做什么”式的描述。

    两种方式都会搜索：工具名、描述、参数名、参数描述。

    延迟加载的最佳实践

    • 工具搜索工具本身不要设置 defer_loading: true
    • 保留 3–5 个最常用工具为非延迟（提升命中与体验）
    • 工具命名与描述尽量贴近用户常用说法（提升可检索性）
    • 适合场景：工具 >10 个、工具定义 >10K token、工具选择准确率下降、MCP 多服务器（200+ 工具）等
    • 不太适合：工具 <10 个且几乎每次都要用、工具定义非常短

    响应与错误处理要点

    • 响应里会出现 server_tool_use（触发工具搜索）与 tool_search_tool_result（返回引用列表）
    • 常见 400 错误：
    • 全部工具都 deferred：至少要有 1 个非延迟工具
    • 引用的工具缺少定义：tool_reference 指向的工具必须在顶层 tools 里有对应定义（并通常设为 deferred）
    • 工具搜索执行期错误（仍返回 200）：如 invalid_pattern、pattern_too_long、too_many_requests、unavailable

    与 MCP、缓存、流式的配合

    • 可与 MCP toolset 结合：用 default_config.defer_loading 控制 MCP 工具默认延迟加载，并可对特定工具覆盖
    • 支持 prompt caching：已发现的工具可在后续轮次复用，不必每次重新搜索
    • 流式返回会把搜索调用与结果作为事件发出，便于前端展示“正在搜索/已找到工具”

    原文链接：https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

    #工具调用 #Agent开发 #上下文优化 #MCP #API设计
    Claude Platform Docs
    Tool search tool
    Tool search tool
    Scale to hundreds or thousands of tools by letting Claude search your tool catalog and load only the tools it needs.

    工具调用Agent开发上下文优化MCPAPI设计

  8. 面条的草稿箱

    代码变便宜了，但“软件”依旧很贵AI 工具把“写代码”的门槛打穿了：越来越多人用 CLI/对话式方式，直接描述需求就能生成一个能跑的应用

    代码变便宜了，但“软件”依旧很贵

    AI 工具把“写代码”的门槛打穿了：越来越多人用 CLI/对话式方式，直接描述需求就能生成一个能跑的应用。结果不是 SaaS 的黄金时代，而是“个人软件”的兴起——为某个具体问题快速做一个小工具，用完就丢，像当年的电子表格一样当作临时工作台。

    但别误会：代码的成本下降，不代表软件的成本下降。真正昂贵的是把东西做成能长期运行、能承受现实摩擦的系统：维护、边界情况、体验债、数据归属与同步、可靠性与扩展性。周末做出的 CRUD+API Demo 很好看，但银行 CSV 格式一变、网页 DOM 一改、离线与多端同步一上，脆弱性立刻暴露。

    当“能写出来”不再稀缺，新的瓶颈转向两件事：

    • 分发与注意力：噪音变大，“一下午做出月入五位数”的叙事很多是营销而非可复制路径。
    • 判断力与系统能力：工程师的价值更偏向架构与取舍——知道该如何组织系统、何时做限流/缓存、哪些变量不能乱放、哪些复杂度必须正面处理。

    谁会在这波变化中受益？有明确领域痛点的专业人士、需要快速解决内部流程的团队、想替换脆弱手工流程的重度用户，以及愿意为“可控与所有权”而不是“高光界面”买单的人。AI 很能加速，但仍需要像审 PR 一样严格复核：它能产出代码，却不负责让软件在现实中长期站住。

    原文链接：https://www.chrisgregori.dev/opinion/code-is-cheap-now-software-isnt

    #AI工具 #软件工程 #产品分发 #架构思维 #个人软件
    www.chrisgregori.dev
    Code Is Cheap Now. Software Isn’t.
    Code Is Cheap Now. Software Isn’t.
    The barrier to entry for building software has collapsed. The barrier to building something that matters hasn’t moved an inch.

    AI工具软件工程产品分发架构思维个人软件

  9. 面条的草稿箱

    Claude Opus 4.5：让“能做”突然变得很容易作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里

    Claude Opus 4.5：让“能做”突然变得很容易

    作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里。

    他用几个真实项目说明差异不在“会写代码”，而在于一次成功率、能自我迭代、能把复杂系统拼起来：

    • Windows 右键图片格式转换工具：从文件资源管理器菜单到打包、安装/卸载脚本、发布网站、GitHub Actions 自动发布，整体接近“一次成型”。遇到报错会自己用 dotnet 构建、读错误、再修复。
    • 录屏与简单剪辑工具：从类似 LICEcap 的录制开始，持续加到视频/图片编辑、裁剪、模糊、标注等功能，作者感叹“几小时就推进到很远”。
    • AI 发帖工具（给小生意用）：iOS 端批量上传照片→AI 生成文案→定时发到 Facebook。后端涉及认证、存储、云函数、日志排错等一堆“胶水活”，但模型能通过 CLI 自己创建资源、查日志并修问题，还顺手做了管理后台。
    • 订单与路线追踪：解析 Gmail 订单、规划路线、统计行驶时间（用于税务），作者强调：这种“手写很痛苦”的 Google/Firebase 集成，Opus 4.5 反而很顺。

    文章也没有回避争议点：
    作者承认自己并不完全理解这些应用“内部怎么搭起来的”（比如 Swift 不熟），但他的焦虑在减轻——因为当问题出现时，模型往往能定位并修复自己的 bug。于是他提出一个更激进的想法：代码也许不必主要面向人类可读，而是面向 LLM 可推理、可重写、可调试。

    他甚至分享了一份自用的“AI-first 编码”提示词要点（概念层面）：

    • 追求可预测、可调试、低耦合、入口清晰、控制流线性
    • 少炫技抽象，减少层级与间接性
    • 该删就删；重构也要分高/中/低优先级
    • 安全需要更谨慎：API key、登录流程、敏感数据存储等不能盲信

    结尾的态度是复杂的：既兴奋于“几小时能做出过去要几周/月的东西”，也沮丧于技能壁垒被压平。但他给出的建议很朴素：别等“都懂了”再开始，继续做东西，只是更快了；同时一定盯紧安全与密钥。

    原文链接：https://burkeholland.github.io/posts/opus-4-5-change-everything/

    #AI编程 #开发者工具 #Claude #软件工程 #生产力
    Burke Holland
    Opus 4.5 is going to change everything
    Opus 4.5 is going to change everything
    Three months ago I would have dismissed claims that AI could replace developers. Today, after using Claude Opus 4.5, I believe AI coding agents can absolutely replace developers.

    AI编程开发者工具Claude软件工程生产力

  10. 面条的草稿箱

    Agent-native 应用：把“功能”变成“结果”这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”

    Agent-native 应用：把“功能”变成“结果”

    这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”。核心在于：让代理拥有与用户同等的操作能力（UI 能做的，代理也能通过工具做到），并把工具设计成足够原子化的“积木”。这样，新功能往往不再是写代码，而是写一段描述结果的提示词；同时，用户提出的意外需求会推动系统“涌现”出新用法，并反过来指导你补齐工具与能力缺口。

    五个核心原则

    • 对等（Parity）：任何 UI 动作，代理都应能通过工具实现同样的结果；否则代理会卡死。
    • 粒度（Granularity）：工具是原子能力；“功能”是代理在循环中用工具达成的结果。改行为优先改提示词，而不是重构代码。
    • 可组合（Composability）：有了原子工具 + 对等能力，就能通过新提示词快速拼出新“功能”（开发者/用户都能做）。
    • 涌现能力（Emergent capability）：用户会提你没设计过的需求；代理若能组合工具完成，就是新机会；若失败，则暴露工具缺口。
    • 持续变好（Improvement over time）：通过沉淀上下文（context 文件）与迭代提示词，应用可在不发版的情况下持续变强。

    落地方法（把原则变成工程实践）

    • 先做“能力地图”：列出用户能做的事，逐项确认代理具备创建/读取/更新/删除（CRUD）能力，避免“能新建不能修改/删除”的断腿体验。
    • 先原语、后领域工具：先用文件、bash、读写等基础工具跑通；再为高频模式加领域工具，用于效率、校验、术语锚定，但不要把“判断”写进工具里。
    • 文件作为通用接口：文件天然可读、可审计、可迁移，代理也最擅长操作；内容放文件、结构化高频数据放数据库（或混合：文件作可读真相，DB 做索引与性能）。
    • 明确完成信号：不要靠“看起来差不多了”判断结束；让工具/编排层返回明确的 complete 信号，避免无限循环或半成品。
    • 透明的代理行为：工具调用、进度、状态变化要让 UI 可见；“沉默的代理”会让用户觉得坏了。
    • 把“授权”做成产品能力：根据风险与可逆性决定自动执行还是强确认；尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死，代理任务却可能很长：需要checkpoint/恢复机制，尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”，但要处理冲突与未下载文件等边界。

    原链接：https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构
    every.to
    Agent-native Architectures
    Agent-native Architectures
    A technical guide for building applications where agents are first-class citizens

    AgentNative软件代理AI产品工具调用产品架构

  11. 面条的草稿箱

    dotagents：用一个 .agents 目录统一管理各类 AI 工具配置dotagents 是一个 CLI/TUI 工具，把项目或全局的 .agents 目录作为“唯一真相源”，自动为不同 AI 工具创建软链接，并支持安装技能（skills）和插件（plugins），方便在多环境之间保持一致配置、可重复执行、易维护

    dotagents：用一个 .agents 目录统一管理各类 AI 工具配置

    dotagents 是一个 CLI/TUI 工具，把项目或全局的 .agents 目录作为“唯一真相源”，自动为不同 AI 工具创建软链接，并支持安装技能（skills）和插件（plugins），方便在多环境之间保持一致配置、可重复执行、易维护。

    你能用它做什么

    • 以 .agents 为中心统一管理：hooks、commands、skills，以及 AGENTS/CLAUDE.md 等说明文件
    • 一键创建软链接，适配多工具（Claude / Codex / Factory）
    • 从本地路径、Git URL、HTTPS URL 安装 skills；并支持从 marketplace 安装 plugins
    • 可随时重复运行，用于补装、修复链接或更新能力集

    快速开始（要求：Bun 1.3+）

    • npx @iannuttall/dotagents
    • 或 bunx @iannuttall/dotagents

    链接关系示例

    • .agents/AGENTS.md → ~/.claude/CLAUDE.md
    • .agents/commands → ~/.claude/commands / ~/.factory/commands / ~/.codex/prompts
    • .agents/hooks、.agents/skills 同步到对应工具目录

    https://github.com/iannuttall/dotagents

    #AI工具 #开发效率 #CLI #Claude #Codex
    GitHub
    GitHub - iannuttall/dotagents: One location for all of your hooks, commands, skills, and AGENT/CLAUDE.md files.
    GitHub - iannuttall/dotagents: One location for all of your hooks, commands, skills, and AGENT/CLAUDE.md files.
    One location for all of your hooks, commands, skills, and AGENT/CLAUDE.md files. - iannuttall/dotagents

    AI工具开发效率CLIClaudeCodex

  12. 面条的草稿箱

    Steel：为 AI Agent 打造的开源云端浏览器基础设施Steel 是一个开源的浏览器 API，用来在云端按需启动并控制“浏览器集群”，让 AI Agent、自动化脚本把能力真正带到网页上运行

    Steel：为 AI Agent 打造的开源云端浏览器基础设施

    Steel 是一个开源的浏览器 API，用来在云端按需启动并控制“浏览器集群”，让 AI Agent、自动化脚本把能力真正带到网页上运行。

    它适合做什么？

    • 大规模网页抓取与数据采集（也支持更稳定的反爬配置）
    • 自主 Web Agent（下单、订票、填写表单等真实操作流程）
    • 模型训练数据采集、AI 购物助手、RPA/销售自动化、QA 测试、客服自动化

    核心能力概览

    • Sessions API：一行调用启动浏览器会话
    • 自动 CAPTCHA 处理：减少流程中断
    • 代理与指纹控制：降低被识别为机器人的概率
    • 快速启动：平均会话启动时间低于 1 秒（同区域更快）
    • 长会话：单个会话最长可跑 24 小时
    • 上下文复用：保存/注入 Cookies 与本地存储，续跑更顺畅
    • 低改动迁移：Puppeteer/Playwright/Selenium 通过少量改动即可上云
    • 可观测性：提供会话查看器，支持实时/录制回放调试
    • 安全登录：帮助自动化访问需要登录的站点

    价格与开源

    • 提供免费档起步（按浏览器小时/代理带宽/CAPTCHA 计量），也有从个人到企业的多档套餐
    • 项目开源，可本地运行或用 Docker 自托管（官方 GitHub 仓库提供）

    原链接：https://steel.dev/
    #浏览器自动化 #AI代理 #Web抓取 #开源工具 #云基础设施
    Steel
    Steel | Open-source Browser Infrastructure for AI Agents
    Steel | Open-source Browser Infrastructure for AI Agents
    Steel is an open source browser API that lets you control fleets of browsers in the cloud.

    浏览器自动化AI代理Web抓取开源工具云基础设施

  13. 面条的草稿箱

    用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出

    用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法

    这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出。

    1) 先换个视角：你不是“追上更新”，而是“借力变强”

    作者给了一个更实用的框架：

    • 跟进工具：定期用、定期看更新（不必天天追）。
    • 深耕领域：懂业务/系统设计/工程习惯，才能把“未知”变成“可提问、可验证”。
    • 多玩多试：用不同模型做同一件事，快速建立直觉与边界。

    2) Claude Code 2.0 值得关注的体验升级

    一些偏“日常效率”的改动，叠加起来很实用：

    • 语法高亮 + 更舒服的评审体验（作者因此更愿意在 CLI 里完成 review）
    • /context 看上下文占用（建议复杂任务到 60% 左右就交接或压缩）
    • Checkpointing（Esc+Esc / /rewind）：能回到某个检查点，回滚代码与对话
    • Prompt suggestions / 历史搜索（Ctrl + R）：减少重复输入
    • 更快的模糊文件搜索、队列导航、LSP 插件 等

    3) Sub-agents（子代理）怎么用才不浪费

    作者重点讲了“子代理不是魔法，是上下文与工具调用策略”：

    • Explore：偏“只读搜索专家”，适合快速扫代码库、定位文件与线索。
    • general-purpose / plan：更像“全能协作者”，通常会继承更多上下文。
    • 关键提醒：不要只依赖 Explore 的摘要。摘要是“有损压缩”，重要文件最好让主代理再读一遍，让信息彼此“交叉注意力”，推理更稳。

    4) 核心概念：Context Engineering（上下文工程）

    代理之所以“烧 tokens”，不是它话多，而是：

    • 工具调用本身 + 工具返回结果都会进入上下文；
    • 上下文越长，检索与注意力越容易退化（作者称为 context rot / degradation）。

    因此，上下文工程的目标是：

    • 把最相关的信息放进来
    • 控制“噪音”和重复指令
    • 用清晰结构（计划、scratchpad、handoff）对抗跑偏

    5) Hooks / Skills / MCP：把“提示词”产品化

    作者把这三者放在一起看：

    • Hooks：在对话生命周期某个节点自动触发脚本（比如 Stop 后自动提醒/继续下一步）。
    • Skills：把领域指令与脚本做成“按需加载”的技能包，避免常驻系统提示导致上下文膨胀。
    • MCP：连接外部工具/服务，但要注意“工具定义与中间结果”同样会吃上下文与成本；文中也提到用代码执行环境来降低这种膨胀的思路。

    6) 一个很实战的工作流建议

    作者的默认搭配大意是：

    • Claude（Opus 4.5）偏执行与沟通：更像结对编程伙伴、反馈快。
    • Codex 偏 review/找 bug：更克制、误报少，适合做“第二视角审查”。
    • 面对难功能：先跑一个“可丢弃的草稿版本”，用它暴露模型的偏差，再用更精准的提示第二轮迭代。

    原文链接：https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/

    #ClaudeCode #编码代理 #上下文工程 #AI工具 #软件工程
    sankalp's blog
    A Guide to Claude Code 2.0 and getting better at using coding agents
    A deep dive into Claude Code 2.0 features, Opus 4.5 workflows, and context engineering. Learn sub-agents, MCP servers, hooks, skills, and practical tips to boost your AI-assisted coding productivity.

    ClaudeCode编码代理上下文工程AI工具软件工程

  14. 面条的草稿箱

    Ref：给你的 AI Agent 一份“刚刚好”的文档上下文做 AI 编程助手最怕两件事：胡编和上下文膨胀

    Ref：给你的 AI Agent 一份“刚刚好”的文档上下文

    做 AI 编程助手最怕两件事：胡编和上下文膨胀。Ref 主打的就是把问题变简单——让你的 Agent 能随用随查公共/私有技术文档，只拿“够用且准确”的信息。

    它怎么做？
    Ref 通过 MCP（Model Context Protocol）把文档上下文接到你的 AI 工具里：既有持续更新的公共文档索引，也支持把你的私有资料（如 GitHub 仓库、PDF）纳入检索。

    给 Agent 的两个核心能力：

    • search_documentation：面向技术文档的精确搜索，能定位到具体章节，支持公有与私有文档集。
    • read_url：读取任意网页或 GitHub 文件内容（可含私有内容），适合顺藤摸瓜跟进链接。

    为什么不是“东拼西凑工具链”？
    你当然可以分别用：代码片段、搜索、爬取、私有代码检索、PDF 检索等工具组合；Ref 的定位是把这些需求尽量合并成一个更统一的入口，减少集成成本与上下文噪音。

    安全与企业能力（官方强调点）：

    • SOC2 合规（并提供 Trust Center 与隐私安全说明）
    • 支持 SSO 与 MCP OAuth
    • 提供“主动提示注入防护”（对返回的上下文做注入扫描，仍在开发中）

    定价概览：

    • Free：200 credits（不刷新、不失效，官方估算约 10 周常规使用）
    • Basic：$9/月，1000 credits
    • Team：$9/月/席位，1000 credits/席位（团队共享私有文档索引与统一账单）
    • Enterprise：SSO、SOC2、优先支持、定制化等

    如果你在用 Claude/Cursor/Zed 等工具做工程开发，且经常需要“查最新文档 + 查公司内部资料”，这种“面向文档的上下文层”会比泛用搜索/爬虫更省 token，也更贴近代码场景。

    原链接：https://ref.tools/

    #MCP #开发者工具 #技术文档 #AI编程助手 #RAG
    ref.tools
    Ref - Review the Plan before the Code.
    Ref - Review the Plan before the Code.
    A shared workspace to review the plan before the diff, so AI creates accountability without slowing people down.

    MCP开发者工具技术文档AI编程助手RAG

  15. 面条的草稿箱

    2025 年 AI 编程现状：效率在涨，工具与模型在分化Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰

    2025 年 AI 编程现状：效率在涨，工具与模型在分化

    Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰。

    1) 工程效率：PR 更大，个人产出更高

    • PR 规模变大：2025 年 3 月到 11 月，PR 的中位改动行数从 57 增至 76，约 +33%。
    • 开发者产出上升：人均代码产出从 4,450 增至 7,839 行，约 +76%，AI 工具被视为“产能放大器”。
    • 中型团队提升更明显：6–15 人团队的人均产出从 7,005 增至 13,227 行，约 +89%。
    • 单文件改动更密：每个文件的改动行数中位数从 18 增至 22，约 +20%，说明 PR 不只变大，也更“集中”。

    2) 工具采用：从“能用”到“形成标准层”

    • 记忆/Memory 基建：mem0 以 59% 份额领跑（按 PyPI + npm 月下载量口径）。
    • 向量数据库：没有绝对赢家；Weaviate 约 25%，其余多家在 10–25% 之间拉锯。
    • AI 规则文件：CLAUDE.md 使用率 67%；不少团队多格式并存，且 17% 的仓库三种格式都用。
    • AI SDK 增长：Anthropic SDK 以 43M 下载领先（约 8 倍增长）；Pydantic AI 增长 3.7× 到 6M。
    • LLMOps：LiteLLM 月下载量增长 4× 至 41M（LangSmith 与 LangChain 安装存在绑定关系）。

    3) 模型格局：生态差距在收敛

    • SDK 下载量：OpenAI 约 130M 领先；Anthropic 自 2023 年 4 月起增长 1,547×；Google 约 13.6M。
    • 差距缩小：OpenAI 与 Anthropic 的下载量比从 2024 年 1 月的 47:1，降至 2025 年 11 月的 4.2:1。

    4) 作为“编程 Agent 后端”，模型各有侧重

    报告用统一参数对多模型做了延迟、吞吐、成本等基准：

    • 首 token 响应（TTFT）：Claude Sonnet/Opus（p50 < 2.5s）明显更快，更利于交互式编程保持“心流”。
    • 生成吞吐：GPT-5 Codex / GPT-5.1 吞吐更高，长输出更快结束，利于并行跑更多 Agent/CI。
    • 成本倍率（以 GPT-5 Codex = 1× 归一）：GPT-5 Codex ≈ GPT-5.1（1×）；Gemini 3 Pro（1.4×）；Sonnet 4.5（2×）；Opus 4.5（3.3×）。

    结论很直接：选型不再是“谁最强”，而是你更在意 响应速度、吞吐效率，还是预算。

    5) 研究方向：规模、上下文与 Agent 的“系统工程”

    报告还汇总了 2025 年影响工具与应用的一批研究线索，包括：

    • MoE 的效率设计（如 DeepSeek-V3：关注 KV cache、路由与训练信号密度）。
    • 长上下文 vs RAG 的边界（不同数据结构下各有优势；以及 KV 级检索等新思路）。
    • Agent 训练与检索策略（用 RL 学会“何时搜索”、如何管理长程记忆、如何降低噪声上下文干扰等）。

    原文链接：https://www.greptile.com/state-of-ai-coding-2025

    #AI编程 #开发效率 #LLM工具链 #模型评测 #软件工程趋势
    Greptile
    Get the State of AI Coding Report | Greptile
    Get the State of AI Coding Report | Greptile
    Read the State of AI Coding report: engineering velocity, tool adoption, and model growth trends.

    AI编程开发效率LLM工具链模型评测软件工程趋势

  16. 面条的草稿箱

    AntV Infographic：面向 AI 时代的声明式信息图引擎AntV Infographic 是一个“声明式”的信息图生成与渲染框架（npm：@antv/infographic），目标是把文字和结构化内容快速变成可视化信息图，降低制作门槛、提升表达效率

    AntV Infographic：面向 AI 时代的声明式信息图引擎

    AntV Infographic 是一个“声明式”的信息图生成与渲染框架（npm：@antv/infographic），目标是把文字和结构化内容快速变成可视化信息图，降低制作门槛、提升表达效率。

    它解决什么问题

    • 用更接近“写文档”的方式描述信息图：通过简洁语法定义标题、描述、数据项、布局与主题
    • 适配 AI 生成：语法容错、配置完整，并支持流式输出与分段渲染，适合大模型逐步生成内容
    • 从 0 到 1 更快：内置约 200+ 模板与组件（时间线、思维导图、流程、金字塔等）

    核心能力

    • 声明式渲染：用配置描述信息图结构与样式，而不是手工拖拽绘制
    • AI 一键生成：AI 理解文本→抽取关键信息→生成配置→渲染成专业信息图
    • 主题与风格：一键切换暗色等风格，也支持自定义主题体系
    • 在线 Playground：浏览器内编辑语法、实时预览，配套示例便于上手

    快速上手入口

    • 学习与文档：/learn
    • AI 生成入口：/ai
    • 示例库：/examples
    • GitHub：antvis/infographic

    原链接：https://infographic.antv.vision/

    #信息图 #数据可视化 #AntV #前端工程 #AIGC
    infographic.antv.vision
    AntV Infographic, an infographic generation and rendering framework that brings words to life.
    AntV Infographic is a powerful visualization library for building interactive and customizable infographics. Create stunning visual stories with ease using our intuitive API and rich set of components.

    信息图数据可视化AntV前端工程AIGC

  17. 面条的草稿箱

    AI SDK 6：从“调用模型”到“构建可复用智能体”Vercel 发布 AI SDK 6，把 TypeScript AI 应用的开发重心从函数式调用（generateText/streamText）进一步推进到可复用、可维护、可观测的 **Agent（智能体）**体系，并补齐了安全审批、MCP 全能力支持、调试工具等关键环节

    AI SDK 6：从“调用模型”到“构建可复用智能体”

    Vercel 发布 AI SDK 6，把 TypeScript AI 应用的开发重心从函数式调用（generateText/streamText）进一步推进到可复用、可维护、可观测的 **Agent（智能体）**体系，并补齐了安全审批、MCP 全能力支持、调试工具等关键环节。

    这次更新最值得关注的点

    • Agents / ToolLoopAgent：用 Agent 抽象把 模型、指令、工具 固化成可复用单元；ToolLoopAgent 提供“模型调用 → 工具执行 → 回填结果 → 继续推理”的生产级循环（默认最多 20 步），同一套定义可在 UI、API、后台任务复用。
    • 工具执行审批（Human-in-the-loop）：工具支持 needsApproval，可按输入内容动态决定是否需要人工确认，适合删除文件、支付、修改生产数据等高风险操作。
    • 工具能力增强：
    • Strict Mode 可按工具粒度开启，避免某个工具 schema 不兼容导致整次请求失败。
    • Input Examples 用“正确示例”提升模型生成工具入参的稳定性。
    • toModelOutput 将“应用拿到的完整结果”和“发回模型的 token 内容”分离，减少大文本/二进制（截图、图片）带来的上下文浪费。
    • MCP（Model Context Protocol）更完整且稳定：新增/完善 OAuth 认证、Resources、Prompts、Elicitation，并在 @ai-sdk/mcp 中以稳定形态提供，便于对接远程 MCP 服务与第一方数据源。
    • 工具调用 + 结构化输出：generateText 与 generateObject 能力统一，支持在多步工具链路后直接生成最终结构化结果（通过 Output.* 声明输出形态）。
    • DevTools 可观测性：通过中间件记录并可视化每一步的输入输出、工具调用、token 消耗、耗时与原始请求/响应，解决多步 agent 调试“黑盒”问题。
    • Reranking（重排序）：新增 rerank，把检索结果按相关性排序，只喂最相关上下文给模型（当前支持 Cohere、Amazon Bedrock、Together.ai）。
    • 标准 JSON Schema 生态：支持实现 Standard JSON Schema 接口的任意 schema 库，降低与特定校验库的绑定成本。
    • 图像编辑：generateImage 支持带参考图的编辑（如修补/扩展/风格迁移等），不再只限于文生图。
    • 更细的返回原因与用量统计：新增 rawFinishReason，并扩展 usage 的输入/输出细分，方便成本优化与兼容不同供应商行为。
    • LangChain 适配器重写：更贴合现代 LangChain/LangGraph，支持流式事件转换、工具调用部分输入流等能力。
    • 更多 Provider Tools：围绕 Anthropic/OpenAI/Google/xAI 等提供平台特性工具（如代码执行、文件搜索、Web/X 搜索、MCP 工具等）。

    升级提示

    从 v5 升级到 v6，可先跑官方 codemod：npx @ai-sdk/codemod v6（文中也提供迁移指南链接）。

    原文链接：https://vercel.com/blog/ai-sdk-6
    #Vercel #AISDK #Agent #MCP #TypeScript
    Vercel
    AI SDK 6
    AI SDK 6
    Introducing agents, tool execution approval, DevTools, full MCP support, reranking, image editing, and more.

    VercelAISDKAgentMCPTypeScript

  18. 面条的草稿箱

    用 Payload CMS + Vercel AI SDK 搭建“可运营”的 AI 应用把 AI 做到生产可用，更多是架构问题：提示词不该写死在代码里，长任务要能可靠重试，Embedding 要能查询，输出要结构化可校验，更关键的是——要能看见系统到底“说了什么、做了什么”

    用 Payload CMS + Vercel AI SDK 搭建“可运营”的 AI 应用

    把 AI 做到生产可用，更多是架构问题：提示词不该写死在代码里，长任务要能可靠重试，Embedding 要能查询，输出要结构化可校验，更关键的是——要能看见系统到底“说了什么、做了什么”。

    这篇文章分享了 InnoPeak 在 FinSureTech 场景下的一套实践组合：用 Payload CMS 做“可视化、可配置的 AI 后端”，用 Vercel AI SDK 做“结构化生成与工具调用的运行层”，形成一条从配置、执行到观测的闭环。

    1) 用 Payload 管理 Prompt 与模型选择（不发版也能调）

    • 把系统/用户提示词做成模板（如 Handlebars），集中放在 Payload 的 globals 里
    • 模型 ID 用受控下拉选项管理，避免随意输入造成线上不可控
    • 非开发同事也能在后台安全修改提示词与模型策略，应用逻辑保持稳定

    2) 在后台“可视化”JSON Schema，提升结构化输出可靠性

    做结构化输出（JSON schema）时，最大的成本在测试与迭代。作者的做法是：

    • 在 Payload Admin 里直接渲染/展示 schema
    • 让开发者一键复制到测试对话或本地 LLM 环境验证

    这样能更快发现：字段缺失、类型不匹配、约束不被遵守等问题。

    3) 用 Payload Jobs Queue 跑长任务：重试、编排、定时都省了

    AI 工作流常有“慢”和“不稳定”：Embedding 生成、文档扫描、分段处理、失败重试……在 serverless 环境尤其麻烦。Payload 的 Jobs Queue 提供：

    • 任务与工作流编排
    • 重试与调度
    • 可用 Vercel CRON 或其他调度器触发

    把“队列基础设施”从应用里剥离出来，专注业务流程。

    4) Embedding 直接存进 Payload 的 Postgres（pgvector），再用 Drizzle 查

    Payload 本身不内建向量字段与索引，但可以用 schema hooks 扩展：

    • beforeSchemaInit 增加 vector 列，让生成的 Drizzle schema 也包含它（全类型化）
    • afterSchemaInit 创建 HNSW 向量索引、以及 GIN 文本索引（便于混合检索）

    随后即可在 API route / server action / task 里做相似度检索与排序，实现 RAG 的“数据库内闭环”。

    5) 记录 Token 与完整消息：成本可控、行为可追溯

    为了线上可观测性，作者在 Payload 里建了 TokenUsage 集合，保存：

    • 输入/输出/总 token（含缓存、推理 token 等）
    • 与模型交互的完整 messages（包含 tool calls）

    并通过 Vercel AI SDK 的 onFinish 钩子自动落库。好处是：复盘提示词与输出、定位异常、优化成本都有依据。

    结论很明确：AI 应用要“能跑、能改、能查、能追踪”，需要的不只是模型能力，更是把配置、数据与运行时纳入同一套可运营系统。

    原文链接：https://finly.ch/engineering-blog/916926-building-ai-native-applications-with-payload-cms-and-the-vercel-ai-sdk

    #PayloadCMS #VercelAISDK #AInative #RAG #可观测性
    finly.ch
    Finly - Building AI-Native Applications with Payload CMS and the Vercel AI SDK
    Finly - Building AI-Native Applications with Payload CMS and the Vercel AI SDK
    How we build AI-native FinSureTech applications at InnoPeak using Payload CMS and the Vercel AI SDK—breaking down real-world patterns for prompts, workflows, and AI-powered features that support modern financial advisors.

    PayloadCMSVercelAISDKAInativeRAG可观测性

  19. 面条的草稿箱

    一份配置，多端通用：MCP Config 转换器mcp-config 是一个参考实现：把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令，避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置

    一份配置，多端通用：MCP Config 转换器

    mcp-config 是一个参考实现：把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令，避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置。

    它解决什么问题

    • 只维护一份 MCP Server 定义（支持远程 HTTP / 本地 stdio）
    • 按目标客户端输出对应格式：JSON / CLI / TOML
    • 适配 30+ 客户端格式，减少迁移与同步成本

    怎么用（概念流程）

    • 将仓库的 src/ 复制到你的项目中
    • 使用 getClients() 查看支持的客户端
    • 用 transformConfig({ server, client }) 生成目标客户端需要的配置字符串（例如 Cursor 的 JSON，或 Claude Code 的添加命令）

    支持范围（示例）

    • JSON 类：Claude Desktop、Cursor、Windsurf、VS Code/Copilot、JetBrains、Zed、Warp、Perplexity Desktop 等
    • CLI 类：Claude Code、Amp、OpenAI Codex CLI 等

    适合谁

    • 同时在多个 IDE/客户端里用 MCP 的开发者与团队
    • 想把“配置维护”从手工劳动变成可复用工具链的人

    原链接：https://github.com/iannuttall/mcp-config

    #MCP #配置管理 #开发工具 #TypeScript #效率提升
    GitHub
    GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.
    GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.
    Turn one MCP server setup into the right format for lots of apps. - iannuttall/mcp-config

    MCP配置管理开发工具TypeScript效率提升

  20. 面条的草稿箱

    MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力

    MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级

    MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力。

    这次重点提升了什么？

    • 多语言编程能力系统增强：覆盖 Rust / Java / Go / C++ / Kotlin / Objective‑C / TypeScript / JavaScript 等，更贴近真实项目的多语言栈协作。
    • Web & App 开发更强、更好看：强化原生 Android / iOS 开发，同时提升设计理解与审美表达，支持复杂交互、3D 场景模拟与高质量可视化。
    • 更适合办公场景的“复合指令”执行：在多约束条件下做端到端任务推进，更强调“按要求完成”而不是只写对代码。
    • 更简洁、更高效的输出：相较 M2，响应更精炼、速度更快、token 消耗更低，适配持续式 AI Coding / Agent 工作流。
    • 更强的 Agent / 工具泛化：官方称在多种编码工具与 Agent 框架中表现稳定，并兼容常见的上下文管理约定。
    • 对话与写作质量同步提升：不仅是“更会写代码”，也更擅长技术文档与日常写作的结构化表达。

    基准与展示

    • 在多项软件工程评测上相对 M2 有明显提升，并强调多语言场景竞争力；同时引入 VIBE（含 Web/Simulation/Android/iOS/Backend）评测体系，用更接近真实运行环境的方式验证“能跑、能交付”。

    如何使用

    • API：已上线 MiniMax Open Platform
    • 产品：基于 M2.1 的 MiniMax Agent 已开放
    • 开源：模型权重提供本地部署，推荐 SGLang / vLLM 等推理框架

    原文链接：https://www.minimax.io/news/minimax-m21

    #MiniMax #开源大模型 #AI编程 #多语言开发 #Agent工作流
    MiniMax
    MiniMax M2.1: Significantly Enhanced Multi-Language Programming, Built for Real-World Complex Tasks

    MiniMax开源大模型AI编程多语言开发Agent工作流

1px