你的 AI 助手,究竟能写出几轮好代码?今日 AI 最前线深度拆解(2026.03.28)

本文约 5500 字，阅读约需 12 分钟。适合希望跟进 AI Agent 最新进展的开发者、产品人与研究者。

你有没有遇到这种情况：让 AI 帮你写代码，第一轮写得挺优雅；第二轮加功能，代码开始臃肿；第三轮改需求，函数嵌套成了俄罗斯套娃；第四轮你发现，AI 居然在重新实现一个它自己上一轮已经写过的函数？

或者这样：你想搭一套多 Agent 系统，结果发现调试的时候根本不知道哪个 Agent 在做什么，像在追一只无形的猫。

再或者：一个万亿参数的科学多模态大模型昨天刚开源了——它真的能”读懂”一张分子结构式、一段蛋白质序列，或者一条地震波形吗？

今天的内容，正好把这几个问题一起回答。

一、AgentScope：你终于可以”看见”你的多 Agent 系统在干什么

今日 GitHub 新增 Stars：+904 ｜ 总计 21.2k

解决了什么问题

多 Agent 系统有一个著名的调试噩梦：你启动了五个 Agent，它们在互相传消息，系统输出了一个错误答案，但你根本不知道是谁在哪一步出了问题。整个过程像黑箱，你只能靠猜。

更现实的问题是，大多数多 Agent 框架在原型阶段很好用，一到生产环境就各种麻烦——部署复杂、监控缺失、跨团队协作难。AgentScope 要解决的，就是这个从”能跑”到”能用”之间的鸿沟。

AgentScope 的 Slogan 说得很直接：”Build and run agents you can see, understand and trust”（构建可见、可理解、可信赖的 Agent）。这三个词背后，是三层工程能力。

技术与产品原理

“可见”——全栈可观测性

AgentScope 内置了 OpenTelemetry 标准支持。每一条消息的流转、每一次工具调用、每一个 Agent 的决策链，都有完整的链路追踪。你可以对接 Jaeger、Grafana 等主流监控系统，在生产环境里像看 Web 服务日志一样看 Agent 行为。

打个比方：如果传统多 Agent 框架是”黑盒快递”，AgentScope 给每个包裹都装了 GPS 和实时温度传感器。

“可理解”——消息中心架构

所有 Agent 之间的通信统一经过一个”消息中心”（Message Bus），这不是新概念，但 AgentScope 的实现让消息本身带有结构化的上下文，而不是纯文本字符串传来传去。这意味着你可以在任意节点”暂停”、”检查”，也可以回放某次对话的完整消息序列。

“可信赖”——MCP + A2A 双协议生态

AgentScope 同时支持 MCP（模型上下文协议）和 A2A（Agent-to-Agent）协议，两个当前最主流的 Agent 间通信标准都兼容，这意味着你用 AgentScope 构建的 Agent，可以直接和市场上其他 MCP/A2A 生态里的工具和服务互通，不需要写胶水代码。

多模型后端：统一支持通义千问（DashScope）、Claude、GPT、本地 Ollama，一套代码可以按需切换，不被任何单一厂商绑定。

快速开始（5 分钟内跑起来一个 ReAct Agent）：

pip install agentscope

from agentscope.agent import ReActAgent, UserAgentfrom agentscope.model import DashScopeChatModelimport asyncioasync def main():    agent = ReActAgent(        name="Friday",        sys_prompt="You're a helpful assistant named Friday.",        model=DashScopeChatModel(            model_name="qwen-max",            api_key="your-api-key",            stream=True,        )    )    user = UserAgent(name="user")    msg = None    while True:        msg = await agent(msg)        msg = await user(msg)        if msg.get_text_content() == "exit":            breakasyncio.run(main())

适合谁用 / 不适合谁用

适合：

• • 正在把多 Agent 系统推向生产环境的工程师，对可观测性有刚性需求
• • 企业/团队内部需要接入多种 LLM 后端（国内+国外），不想被某家模型绑定
• • 需要与 MCP 或 A2A 生态中其他工具互通的开发者
• • 希望快速搭建具有语音交互能力的 Agent（内置 TTS + Human-in-the-Loop）

不适合：

• • 完全个人项目、不关心可观测性的快速原型——LangChain 或直接用 SDK 可能更轻
• • 对国际化生态优先（英文社区、更丰富插件）有强需求——LangGraph 社区更成熟
• • 需要极低延迟、对框架额外开销零容忍的场景——裸调 API 更合适

项目地址：https://github.com/agentscope-ai/agentscope

二、AI-Scientist-v2：一个 AI 系统，第一次通过了学术同行评审

今日 GitHub 新增 Stars：+143 ｜ 总计 2.8k

解决了什么问题

科学研究的完整链条是：发现问题 → 提出假设 → 设计实验 → 运行实验 → 分析结果 → 写论文 → 接受同行评审。

AI 在其中某个环节帮忙，已经不新鲜了。但有没有一个系统，能完整走完这整条链条，并且产出的论文被人类学者评审后认为”值得接受”？

Sakana AI 的 AI-Scientist-v2 做到了这件事——其输出的论文，是全球首篇完全由 AI 撰写并通过学术工作坊同行评审的论文。

这不是概念演示，而是可运行、可复现的开源系统。

技术与产品原理

核心机制：最优先树搜索（BFTS）

v1 版本使用线性思路探索研究假设，而 v2 引入了”最优先树搜索”（Best-First Tree Search）。

类比一下：v1 像一个研究员每次只追一个假设，跑完一个实验再跑下一个；v2 像一个有完整实验室的科研组——可以同时维护多条假设分支，优先推进最有希望的那条，但不丢弃其他分支。这在探索复杂研究空间时效率远高于线性搜索。

完整闭环：从假设到 PDF

整个执行流程分两步：

第一步，生成研究想法：

python ai_scientist/perform_ideation_temp_free.py \  --workshop-file "ai_scientist/ideas/your_topic.md" \  --model gpt-4o-2024-05-13 \  --max-num-generations 20

第二步，运行实验 + 自动撰写论文：

python launch_scientist_bfts.py \  --load_ideas "ai_scientist/ideas/generated_ideas.json" \  --model_writeup o1-preview-2024-09-12 \  --model_review gpt-4o-2024-11-20 \  --num_cite_rounds 20# 输出：experiments/时间戳_主题名/paper.pdf

系统会自动检索 Semantic Scholar 数据库做文献去重和引用补全，用 LaTeX 排版，最后输出一份格式完整的 PDF 论文——包含摘要、实验设计、结果图表和参考文献。

支持的 LLM 后端：GPT-4o/o1、Claude（通过 AWS Bedrock）、Gemini 等。研究写作阶段推荐用 o1-preview 或 Claude Opus 等强推理模型，评审阶段用 GPT-4o 即可。

关于许可证：项目采用特殊的 Responsible AI License，要求在使用 AI 生成的论文时必须明确披露 AI 参与，不可隐瞒。

适合谁用 / 不适合谁用

适合：

• • AI/ML 研究者想快速探索某个方向的可行性，生成研究”毛坯”后人工精修
• • 想了解”AI 做科研”技术路线的工程师，作为学习案例
• • 需要快速产出大量实验性假设用于后续筛选的研究组
• • 对 agentic tree search 在科研中的应用有学术兴趣

不适合：

• • 直接用于正式投稿顶级期刊（当前系统成功率有限，且学术诚信有明确要求）
• • 资源有限的个人开发者——需要 CUDA GPU + 大量 API 调用费用，单次跑下来成本不低
• • 非机器学习领域的科研（当前对 ML 领域优化程度最高，其他领域效果未知）
• • 期望系统”全自动无需干预”——v2 仍需人工配置研究方向和审核结果

项目地址：https://github.com/SakanaAI/AI-Scientist-v2

三、SlopCodeBench：你的 AI 编程助手，迭代 5 次之后代码变成什么了？

论文：arXiv:2603.24755 ｜ 威斯康星大学麦迪逊分校 + Snorkel AI

解决了什么问题

现在几乎所有主流的 AI 编程基准——SWE-bench、HumanEval、MBPP——衡量的都是单次生成的能力：给你一个任务，写出来，跑通测试就算成功。

但真实的软件开发从来不是这样的。你会迭代：加功能、改需求、修 Bug，一个代码库会被同一个 AI 助手改十次、二十次。

SlopCodeBench 研究的问题是：当 AI 编程助手反复迭代同一个代码库，代码质量会怎么变化？

结论令人警醒。

技术与产品原理

“Slop”是什么

研究团队造了一个词：”Slop”（可以理解为”垃圾代码”）。他们设计了 20 个需要多轮迭代的编程任务，每个任务包含 93 个检查点（Checkpoint），每个检查点对应一次需求演进——规格说明会不断推进，但不限定内部实现方式，以此迫使 AI 做出真正的架构决策。

跑了 11 个主流大模型后，他们测量了两个质量指标：

• • 冗余度（Redundancy）：代码里有多少重复或多余的部分
• • 结构侵蚀（Structural Erosion）：复杂度有多集中于少数函数（函数越来越臃肿的信号）

数字有多触目惊心

与 48 个真实开源 Python 代码库对比后发现：人类写的代码质量随时间保持平稳，AI 迭代的代码质量持续恶化。

四种典型”Slop”行为模式

研究者给这些行为起了很有意思的名字：

1. 1. 选择性失忆：AI 忽视自己上一轮写的代码，重新实现相同功能，然后两份实现并列存在
2. 2. 库厌恶症：明明可以用 Pandas 解析 CSV，AI 偏要手写解析逻辑，从零开始
3. 3. 删除恐惧症：已经过时的代码，AI 就是不删，代码库越来越臃肿
4. 4. 复杂度螺旋：遇到问题打补丁而不是重构，函数嵌套越来越深，可读性趋近于零

提示工程有用吗？

研究测试了是否可以通过改进 Prompt 来阻止这种退化。结论是：可以提高初始质量，但无法阻止后续退化。这是一个根本性的问题，不是 Prompt 技巧能解决的。

对工程实践的指导意义

这篇论文不是在说”别用 AI 写代码”，而是在说：

1. 1. 选型时不要只看单轮基准。如果你在评估一个 AI 编程工具，要在迭代场景下测试，而不是只看 HumanEval 分数。
2. 2. 引入架构检查流程。在 AI 辅助开发中，每隔若干轮迭代应人工做一次架构审查，尤其看冗余度和函数复杂度。
3. 3. 首轮 Prompt 要明确代码规范。虽然无法阻止退化，但首轮的结构规范要求（单一职责、禁止重复实现）会延缓退化速度。
4. 4. 这是训练数据问题。当前代码 SFT/RLHF 数据缺乏”迭代质量”维度，是模型训练的改进方向。

官网：https://www.scbench.ai ｜ 代码：https://github.com/SprocketLab/slop-code-bench

四、Intern-S1-Pro：万亿参数的科学大脑，能读懂分子式和地震波形

论文：arXiv:2603.25040 ｜ 上海人工智能实验室 ｜ HuggingFace 今日 #2 热门（86 upvotes）

解决了什么问题

现有开源大模型在科学专业领域有一个集体短板：化学合成、晶体热力学预测、蛋白质功能推断——这些任务上，GPT-4o 和 Claude Opus 等专有模型明显优于开源模型，而开源模型又因为不公开权重无法私有化部署和微调。

Intern-S1-Pro 是上海人工智能实验室（InternLM 团队）发布的全球首个万亿参数科学多模态基础模型，目标是同时解决两个问题：足够大、足够专。

技术与产品原理

架构：1 万亿参数 MoE，512 个专家

参数量只是一个数字，关键是架构设计：

• • 总参数 1T（万亿），但每个 Token 只激活其中 22B 的参数（通过 512 个专家中的 8 个）——这是混合专家（MoE）架构的精髓：总容量大，但每次计算成本可控
• • 语言基础：在 Qwen3 235B MoE 上扩展
• • 视觉编码器：InternViT-6B（60 亿参数的视觉编码器，处理图像输入）

打个比方：这个模型像一个医院，里面有 512 个不同专科医生。每次来一个病人（Token），医院自动派出最合适的 8 个医生会诊。总医生数超过”万人医院”，但每次会诊只需 8 个人参与，效率和专业性都有保证。

科学数据能力

在 5 万亿 Token 训练数据中，超过 2.5 万亿是科学领域数据。模型原生理解以下特殊格式：

• • 分子 SMILES 式（化学结构表示法）
• • 蛋白质氨基酸序列
• • 地震时序信号（支持 10^0 到 10^6 量级的时间序列）
• • 数学公式、LaTeX 排版的科研论文

位置编码创新：采用 Fourier Position Encoding（FoPE），比传统 RoPE 更适合处理科学数据中常见的长序列和异构时序数据。

基准性能（235B 版本，Pro 在此基础上进一步提升）：

在化学和材料科学基准上，235B 版本已经超越 Gemini-2.5 Pro。万亿参数的 Pro 版在此基础上进一步提升，官方描述为”在科学专业任务深度上超越专有模型”。

工程部署

官方支持三大主流推理框架：LMDeploy、vLLM、SGLang，模型权重已在 HuggingFace 和 ModelScope 开放下载。提供三个规格选择：Intern-S1-mini（8B，资源受限场景）、Intern-S1（235B MoE，企业级）、Intern-S1-Pro（1T MoE，科研旗舰）。

适合谁用 / 不适合谁用

适合：

• • 化学、材料、生物信息学、地球科学等专业领域的研究人员和工程师
• • 需要私有化部署科学领域智能问答或数据分析的机构（大学、研究院、药企）
• • 想构建科学领域垂直 Agent（分子设计、反应预测、材料发现）的团队
• • 对 MoE 架构在超大规模模型上的工程实现感兴趣的开发者（XTuner + LMDeploy 训练管线开源）

不适合：

• • 个人开发者或中小团队——1T 参数部署需要多机多卡高端 GPU 集群，门槛极高
• • 通用文字工作场景（写作、摘要、客服）——专科医院来看感冒，大材小用
• • 需要低延迟实时响应的场景——超大 MoE 推理延迟相对较高

论文：https://arxiv.org/abs/2603.25040 ｜ 代码：https://github.com/InternLM/Intern-S1 ｜ 在线体验：https://chat.intern-ai.org.cn/

今日全局解决方案映射表

以下为本期新收录的 6 个项目/论文。历史全表见 solution-map.md。

作者：AI 最前线 ｜ 每日拆解 GitHub 和 arXiv 热门 AI 项目

如果今天的内容对你有帮助，欢迎转发给同样关注 AI 工程进展的朋友。

下期见。