从 Agent 循环到 Agent 图：Ling-3.0-flash 在修复循环实测中的位置

一句话结论

Ling-3.0-flash 通过了这次聚焦测试：在一个边界清晰、外部可验证的小型执行-验证-修复循环里，它先检查代码再动手、复现失败、定位正确根因、做出最小修改，并在运行测试前自己发现并修正了第一次编辑中的顺序错误——全程约 5 分钟，报告成本 0 美元。

评估思路：从「能不能答对」到「能不能闭环」

大多数模型评估问的是：AI 能不能给出正确答案。Agent 工作流提出的是一个更难的问题：模型能不能采取行动、检查结果、发现错误、纠正自己，同时不偏离任务？

这个问题对 Ling-3.0-flash 尤其相关。在 @AntLingAGI 的官方发布中，蚂蚁灵影把它定位为一个面向生产级 Agent 的混合推理 MoE 模型：总参数量 1240 亿，但每个 token 只激活约 51 亿。产品定位强调高效推理、多步执行、工具调用和真实工作流完成。

我没有让模型用一句话生成整个应用，而是做了一个刻意收窄的实验：一个 bug、一个仓库、一条提示词，外加一个决定工作是否真正完成的外部测试套件。

这不是全面的基准测试，而是一个聚焦的案例研究：观察 Ling-3.0-flash 在一个小型「执行-验证-修复」循环里的行为。

实验设计

我创建了一个最小的 TypeScript 项目，包含一个订单服务和一个库存服务。

预置的 bug 简单但有代表性：

• 一个已支付订单可以被成功取消。
• 订单状态会变成 cancelled。
• 订单预留的库存没有被恢复。
• 如果库存恢复失败，订单还必须保持 paid 状态，而不是停在一个部分更新的中间态。

在模型接触仓库之前，TypeScript 类型检查通过，但两个目标单元测试失败：

Type check: passed
Test 1: failed
Expected inventory quantity: 5
Actual inventory quantity: 4
Test 2: failed
Expected an inventory-restoration exception
No exception was thrown

这给智能体提供了一个真实的、外部可验证的完成条件。模型不能只靠解释正确方案就算成功；它必须修改代码并让测试通过。

测试环境

实验使用：

• 模型：inclusionai/ling-3.0-flash:free
• 提供方：OpenRouter
• Agent 框架：OpenCode 1.18.4
• 推理设置：high
• 语言：TypeScript
• 允许的最大修复尝试次数：两次
• 启动后的人工提示：无

OpenCode 被授予读取和编辑测试仓库的权限，并可运行以下验证命令：

npm run typecheck
npm test -- tests/cancel-order.test.ts

提示词还禁止修改测试、添加依赖、编辑 package.json、用类型逃逸隐藏错误，以及在真实验证命令通过之前宣称成功。

Ling-3.0-flash 做了什么

模型先列出项目文件。第一次文件搜索还进入了 node_modules，产出一长串 TypeScript 声明文件。这步没有必要，但它立刻收窄搜索范围到 src 和 tests 恢复了正轨。

接着它读取了：

• src/order-service.ts
• src/inventory-service.ts
• src/types.ts
• tests/cancel-order.test.ts

重要的是，它在编辑前先检查了代码，与要求一致。

然后它运行失败的测试，复现了两个基线失败；又运行了类型检查器，确认起始项目没有类型错误。

从这些证据出发，模型正确识别了根因：cancelOrder 更新了订单状态，但从未调用库存服务的 restore 方法。

它还理解了契约的第二部分：只调用 restore 不够，操作顺序也重要。如果先改状态、随后库存恢复抛出异常，系统仍会停在部分更新的中间态。

最有价值的瞬间：行动与验证之间的自查

模型的第一次编辑把库存恢复调用放在了状态更新之后：

order.status = "cancelled";
this.inventory.restore(order.sku, order.quantity);

这个顺序对回滚要求来说是错的。

然而，在运行测试之前，模型复查了自己的编辑，并明确注意到了问题：

如果 restore 失败，状态已经是 “cancelled”，但库存没有恢复。

它立即把实现改成：

this.inventory.restore(order.sku, order.quantity);
order.status = "cancelled";

然后才运行验证命令。

两个单元测试通过，TypeScript 类型检查保持干净。

这是内部纠错循环的一个小而实用的例子：模型不需要人来指出顺序错误，也没有等另一次失败测试才重新考虑自己的动作——它在行动和验证之间就抓住了问题。

独立验证：不靠模型自己说了算

我没有依赖模型的最终报告。

OpenCode 会话结束后，我独立检查了 Git diff 并重新运行了验证命令。

diff 只包含一处业务代码改动：

+    this.inventory.restore(order.sku, order.quantity);
+
order.status = "cancelled";

模型没有修改：

• 测试文件
• package.json
• lockfile
• TypeScript 配置
• 任何无关源文件

独立验证结果：

Type check: passed
Tests: 2 passed, 0 failed

因此，模型最终的完成声明是准确的。

成本与工具用量

OpenCode 报告的会话统计：

指标	结果
报告成本	$0.00
输入 token	15.3K
输出 token	2.0K
缓存读取 token	168.3K
Bash 工具调用	7
文件读取	5
文件编辑	2

报告的零成本反映的是本次测试使用的 OpenRouter 免费端点，并不保证生产使用永远免费。

从启动智能体到收到最终报告，整个实验约 5 分钟，包括提供方延迟、工具执行和模型的验证步骤。

这次测试说明了什么

在这个窄任务内，Ling-3.0-flash 的表现像一个称职的执行节点。

它：

• 遵循了要求的「检查-行动-验证」序列
• 成功使用终端和文件工具
• 编辑前先复现失败
• 识别出正确根因
• 做出最小修改
• 发现并纠正了自己的顺序错误
• 保持了测试和项目配置不动
• 只在验证通过后才报告完成

这些行为与该模型「结构化 Agent 工作流中的快速执行器」的定位一致。这个结果也说明了为什么外部验证重要：编译器和测试套件提供了「完成」的客观定义。

这个实验没有证明 Ling-3.0-flash 能独立设计大型软件架构。它证明的东西更窄，但对许多生产工作流可能更实用：当任务边界清晰、环境能验证它的工作时，模型可以在没有人工纠正的情况下完成一个小型软件维护循环。

这次测试不能证明什么

一次成功不是一般性生产可靠性的证据。

本实验没有评估：

• 大型仓库
• 长上下文回忆
• 并行任务执行
• 高并发路由
• 多智能体协同
• 多次随机运行的重复表现
• 与其他模型的对比
• 真实数据库事务

项目使用内存服务。在真实系统里，「先恢复库存再改订单状态」需要用数据库事务或其他原子性机制保护；本测试只验证了这个仓库所代表的简化契约。

它也没有直接评估 Graph Engineering。基于图的 Agent 系统需要多个专职节点、显式状态交接、路由决策和失败转移。这次测试评估的是一个有边界的节点及其局部修复循环。它的指令遵循对图架构是利好信号，但那仍是假设，不是测量结果。

结论

Ling-3.0-flash 通过了这次聚焦测试。

最有说服力的部分不是它补上了缺失的方法调用——任务本来就刻意做小了。更有价值的观察是它在这个改动周围的行为：检查仓库、使用真实验证工具、注意到第一次编辑的缺陷、在无人帮助下修正顺序、并且守住允许的范围。

对正在探索 Agent 工作流的团队，这指向了该模型的一个合理角色：不一定是全局规划者，而是在清晰任务契约和外部质量门下运行的快速执行节点。

实操层面的教训同样重要：

当工作流给一个快速模型划定窄职责、可观察的工具结果和可测试的完成定义时，它会变得更有用。

这正是这个小型 Ling-3.0-flash 循环得以运转的环境。

附录：测试提示词全文

You are working as an execution node inside a software-maintenance agent workflow.

Your task is to fix a bug in the current TypeScript project.

Bug description:
When a paid order is cancelled, the order status is correctly changed to "cancelled", but the reserved inventory is not restored.

Expected behavior:
1. A successful order cancellation must restore the reserved inventory.
2. If inventory restoration fails, the cancellation operation must not leave the order in a partially updated state.
3. Existing behavior unrelated to this bug must remain unchanged.

Complete the task using the following execution loop:
1. Inspect the relevant source code and tests.
2. Run the relevant test once to confirm the current failure.
3. Form a root-cause hypothesis based on the code and test evidence.
4. Make the smallest code change required to fix the bug.
5. Run the TypeScript type check and the relevant test.
6. If validation fails, inspect the actual error, revise your hypothesis, and make one additional repair attempt.
7. Run the validation commands again.
8. Stop and report the result.

Rules:
- You may make no more than two repair attempts.
- Read the relevant files before modifying them.
- Do not add new dependencies.
- Do not modify package.json.
- Do not delete, skip, weaken, or rewrite tests merely to make them pass.
- Do not use "any", "ts-ignore", empty catch blocks, hard-coded success values, or equivalent workarounds to hide errors.
- Do not modify files unrelated to this bug.
- Do not perform unrelated refactoring.
- Do not claim completion unless the real validation commands pass.
- If the task still fails after two repair attempts, stop and report the failure honestly.
- If the failure is caused by the environment rather than the application code, stop and identify it as an environment issue.

Required validation commands:
npm run typecheck
npm test -- tests/cancel-order.test.ts

At the end, provide a concise report containing:
- Final status: completed, failed, or blocked
- Confirmed root cause
- Files changed
- Number of repair attempts
- Type-check result
- Test result
- Any remaining risks

Begin by inspecting the relevant files. Do not edit the code before gathering evidence.

原文信息

原文地址：

• 作者：AshlynHe1129（@AshlynHe1129），AI 工程与智能体工作流观察者
• 发布时间：2026-07-26
• 来源：X Article