在过去的数个月内，我向 GitHub 上的一个 C++ 高性能量化框架hikyuu提交了很多 PR。在此过程中，我积累了一些比较好用、可以复用的经验，在此做一个整理。

关于Repo的一切#

这是一个非常庞大的高性能量化回测框架，里面不仅有 C++，还有 Python。如果单靠人去做优化、做贡献，很难去读懂这个框架。

我因为对量化交易比较感兴趣，于是偶然之间发现了这个框架。对我而言，稳定性、高效性和持续维护是一个框架被我使用的关键。

然而因为量化回测的特殊性，我需要确保我所使用框架的代码是自主可控的、正确的。于是我使用现在非常常见的 Coding Agent 对整一个 Repo 进行了深度详细的扫描。在其中发现了很多和正确性相关的 bug。于是我便开始着手进行修复工作。

关于开发环境#

一些环境的搭建#

C++ 的环境之前少接触到。以前上学校的 C++ 课时下了一个 Visual Studio 2022，于是我就理所应当地把这个环境复用下来了。由于我本机上没有 GCC，所以我就使用了 VS 2022 的 MSVC 作为本次实践的编译环境方案。

我使用 Git 对这个代码库进行了分支操作，在本地开了一个专门用于本地编译环境适配的 Branch。

模型的选择#

在整个开发过程中，我非常喜欢使用的模型就是部署在 Ollama Cloud 上面的智谱 GLM 5.2，以及当时还采用了 Kimi 官方的 Coding Plan Kimi K3 进行整个开发修复。Codex 里面的 GPT 5.5 在当时也参与了部分 PR 的修复与提交。

同时使用了 Gemini 3.1 Pro Preview 进行结构的审计和质量监控。

Harness 选型#

本次我们主要使用智谱的 ZCode 作为我们的 Harness 环境，同时，我们也部分采用 Codex 作为 Harness。

C++ 在整体的评测集与模型开发过程中，一直以来都不是一个关注度非常高的领域。例如 DeepSWE 里面的评测集里，没有一例是 C++ 的评测案例。所以说，对于 Agentic Coding 的流程结构优化就至关重要。

DeepSWE v1.1 的 113 个任务中，没有 C++ 任务

DeepSWE v1.1113 个任务 · 2026-09-11 快照
每格 = 1 个任务选中语言
C++
0 / 113
占样本 0% 没有对应任务
选择语言，对比它在样本中占据的位置。
数据来源与统计口径
  • 数据快照：2026-09-11，DeepSWE v1.1，本地记录的提交为 0b9fabb。
  • 语言分布：Go 35、TypeScript 34、Python 34、Rust 5、JavaScript 5，合计 113；C++ 为 0。

Agent coding 流程结构优化#

现代模型一般都是 MoE 模型，拥有较大的训练参数以及相对较小的激活参数。也就是说，MoE 模型每次运行时它们的激活参数都是不一样的，所以模型的表现也经常没有那么稳定。同时我们发现，几乎所有的模型在每一个特定评测集上的效果都非常好。

这就引出了一个思考：我们该如何更强、更大程度地去激活模型的能力。

分而治之，让模型激活正确的参数#

在 2025 年及之前，大部分模型训练能力的侧重点都在它的数学能力和逻辑能力上。在 2026 年开始，模型逐渐开始面向 Agent 能力进行训练。也就是说，目前市面上模型不仅同时拥有极高的逻辑能力，又有极高的 Agent 长程任务执行能力。但是为什么我们在写代码的过程中，模型通常没有能够正确地执行，去表现出它那非常优秀的逻辑能力呢？

答案是：这两块能力并不是一个完美交叉融合的能力。就像人一样，当人既要去思考，又要去说话的时候，其实是非常困难的。

那我们如何去真真正正地、更充分地调用它们这两块能力呢？

很简单，拆任务。

将面向逻辑和数学思考的任务，与面向执行的代码任务，拆分成两大块。

举个例子，比如我们在进行一个后台开发任务，我们面临的问题是纠缠不清的、超级超级巨大的代码库，然后我们要在里面去改动超级超级难缠的年老 bug。那我们一般的思路是什么呢？没错，就是找到它调用链的逻辑，给出一个计划，并开始修改代码，执行测试。

我们去用 AI 写代码也是一样的。

例如我自己在做的工作就是：

  1. 深度梳理一下整个代码库，找到跟这个任务相关的状态机调用链，把它做成一个数学抽象，以字符画的形式展示出来。
  2. 对这个抽象状态机和调用链进行深度的数学拓扑分析，找出其中的冲突点、矛盾点和 bug，给我一个报告。
  3. 使用 SubAgent 深度 review 一下整个任务相关的代码，理清它所有可能涉及到的上下文调用链，并给出一个可执行的、良好的方案。
  4. 开始执行并完成所有的测试。
  5. 使用 Subagent 对测试做一下实质性审查，并对代码做一下质量审计。

把推理、执行与审查分开，通过明确的产物交接完成五步工作流

推理 · 1—3执行 · 4审查 · 5
  1. 相关代码 → 状态机与调用链模型
  2. 模型分析 → 冲突点与 Bug 报告
  3. SubAgent 回读上下文 → 可执行方案
  4. 实施方案 → 代码补丁与测试结果
  5. SubAgent 审查测试与代码 → 审查结论
输入任务相关代码与调用链
本步产物状态机 + 调用链模型
1 / 5 · 推理

就是一个这样非常非常简单的方案，但是它能够让 DeepSeek V4.1 Flash 直接打败 GPT-6 Astra。（没错，之前帮我朋友理清代码库并找到修复 bug就是用这一招，百试不爽。）

不过这个经验基本上只局限于后端的部分任务，至于前端的一些任务，那就只能大伙探索了….

结语#

随着Agentic Coding的发展，模型的能力越来越强，应该越来越多的人都会意识到好的工程对于模型能力提升的帮助。

希望大伙玩的开心。

Happy coding!