Claude Code和Codex做数学建模：从提示词到Agent工作流实战

从「提示词仓鼠」到Agent工作流

数学建模比赛历来以「爆肝」著称——通宵读题、建模、写代码、调参、排版论文，一套流程下来往往需要三天三夜。以国内规模最大的全国大学生数学建模竞赛（CUMCM）为例，每年9月超过15万支队伍在72小时内完成从问题分析到论文提交的全流程；而美国大学生数学建模竞赛（MCM/ICM）同样要求参赛队在4天内提交完整的英文论文。这种极端的时间压力和跨学科综合能力要求（涉及数学建模、编程实现、数据分析、学术写作等多个环节），天然地使数学建模成为AI辅助工具最具落地价值的应用场景之一。

而近期一位B站UP主「大师兄」分享的实战教程，展示了如何借助 Claude Code 和 Codex 这类代码智能体（coding agent），将整套数学建模流程交由 AI 自动完成。

视频中提到一个耐人寻味的现象：全网充斥着「一键生成国奖论文」「500条提示词大礼包」等营销内容，但真正比赛时，很多人依然不知道 AI 到底该怎么用。作者将这种收藏大量提示词却不会实战的行为称为「练单」，最终大家都变成了「提示词仓鼠」。

本文的核心观点在于：与其追逐提示词军备竞赛，不如从底层理解一套 AI Agent 工作流。这才是从「问答式使用」跃迁到「让 AI 替你干活」的关键。

智能体与传统大模型的本质区别

作者首先厘清了一个关键概念——agentic coding（智能体编程）。

Agentic coding 是2024年以来AI编程领域最重要的范式转移之一。其核心思想源自强化学习中的Agent概念——一个能感知环境、做出决策并采取行动的自主实体。在软件工程语境下，这意味着AI不再只是一个被动的代码补全工具（如早期的GitHub Copilot），而是演变为一个能理解任务目标、自主规划执行步骤、调用外部工具、并根据反馈迭代修正的完整执行系统。

要理解这一演进脉络，可以回顾AI编程工具的三代发展：第一代是基于规则的静态分析工具（如早期的IDE自动补全）；第二代是基于机器学习的代码建议工具（如2021年推出的GitHub Copilot），它们利用大语言模型预测下一段代码，但本质上仍是「补全」而非「执行」；第三代就是当前的Agentic coding，模型从「建议者」升级为「执行者」。这种模式的技术基础是大语言模型的function calling（函数调用）能力和ReAct（Reasoning + Acting）推理框架，后者由普林斯顿大学Shunyu Yao等人于2022年提出，核心创新在于让模型在推理过程中交替进行「思考」（Thought）和「行动」（Action）两个步骤，并通过「观察」（Observation）获取环境反馈，形成一个Thought → Action → Observation的循环。相比纯链式推理（Chain-of-Thought），ReAct让模型能够在推理过程中动态获取外部信息并修正方向，这正是Agent「自主干活」的底层逻辑。

像 DeepSeek、豆包这类对话工具，本质上是「只能回答却不能替你干活」的。用户提问，模型给出文本回答，仅此而已。而 Claude Code、Codex 这类代码智能体则是「专门为了干活而生的」——用户抛出任务后，模型会自主推理、决策，然后调用相应工具获取结果，再继续推理、再调用工具，如此循环直到完成任务。从系统架构看，这种差异可以用一个简洁的对比来理解：传统对话模型的工作模式是「输入 → 输出」的单次映射，而Agent的工作模式是「输入 → [推理 → 决策 → 行动 → 观察]×N → 输出」的多轮迭代循环。

这种差异在数学建模场景尤为明显：

• 传统方式：一问一答式的低效交互，每一步都需要人工引导
• 智能体模式：只需把题目输入进去，AI 自己读题、建模、写代码、跑实验、修 bug、画图，直到生成论文初稿

简单来说，传统大模型是「顾问」，Agent 是「执行者」。

环境搭建：Git、VS Code与Claude Code

要跑通这套 Agent 工作流，需要安装三个基础工具。

Git：AI的「后悔药」

Git 是代码版本管理工具，作者将其比喻为「AI 的橡皮擦」。就像写作业出现笔误可以擦掉重写，当 AI 生成的代码有任何不满意之处，都可以通过 Git 随时回退到之前的版本。

Git由Linux之父Linus Torvalds于2005年创建，最初用于管理Linux内核的分布式开发，替代当时因授权纠纷而无法继续使用的商业版本控制系统BitKeeper。Git的革命性设计在于其分布式架构——每个开发者的本地仓库都包含完整的项目历史，无需依赖中央服务器即可进行版本管理。在传统软件开发中，Git的核心价值是多人协作和版本追溯。但在AI Agent工作流中，Git扮演了一个全新角色：它成为了Agent自主迭代过程中的「安全网」。由于代码智能体会自主修改文件、运行命令甚至重构代码结构，一旦Agent在某次迭代中做出了错误决策（比如删除了关键函数或引入了破坏性改动），Git的分支（branch）和回退（checkout/reset）机制可以让用户瞬间恢复到任意历史状态。这种「可撤销性」对于AI驱动的自动化流程来说是不可或缺的安全保障——毕竟 AI 也会「跑偏」。在实际操作中，一个推荐的最佳实践是在Agent执行每个关键步骤前自动创建Git commit，形成细粒度的版本快照，这样即便Agent连续做出多步错误操作，也能精确回退到任意中间状态。

VS Code：可视化的操作台

VS Code（Visual Studio Code）是微软于2015年推出的开源代码编辑器，凭借其轻量级架构、丰富的扩展生态和跨平台支持，已成为全球开发者使用最广泛的代码编辑器（Stack Overflow 2023年开发者调查显示其市场份额超过73%）。在AI Agent工作流中，VS Code的价值不仅在于代码编辑本身，更在于其强大的扩展机制——通过Extension API，第三方工具可以深度集成到编辑器中，提供内联代码建议、终端控制、文件系统操作等能力。配合官方的 Claude Code 插件，可以将黑框式的命令行操作转化为可视化界面，大幅降低新手上手门槛。用户可以直观地看到Agent正在读取哪些文件、修改了哪些代码行、执行了什么命令，而不是面对一个不断滚动的终端窗口。

Claude Code / Codex：核心智能体

这是整套工作流的大脑。Claude Code由Anthropic开发，基于其Claude系列大语言模型，专门针对代码理解和生成任务进行了优化。而OpenAI的Codex最初是一个独立的代码生成模型（也是GitHub Copilot的底层引擎），后来逐步与ChatGPT产品线整合。说个细节，OpenAI 的 Codex 已与 ChatGPT 合并，因此下载时显示为 ChatGPT 属于正常现象，并非出错。

对于国内用户，作者也给出了务实的方案：通过 CitySwitch 这类工具接入第三方模型 API（如 DeepSeek），绕开官方服务的网络与充值限制。API Key（应用程序接口密钥）是云服务中标准的身份认证机制，用于标识调用者身份并进行用量计费。在大模型服务领域，OpenAI、Anthropic、DeepSeek等厂商均通过RESTful API提供模型调用服务，按输入/输出token数量计费。所谓token，是大语言模型处理文本的基本单位，一个中文汉字通常被编码为1-2个token，而一个英文单词通常对应1-3个token。以GPT-4o为例，其输入价格约为每百万token 2.5美元，输出价格约为每百万token 10美元。第三方中转服务的工作原理是充当API代理（proxy），将用户的请求转发至目标模型服务商，同时解决国内用户面临的网络访问限制和海外支付难题。配置时需要正确填写 API Key、请求地址（通常以 v1 结尾）以及模型映射——即将第三方接口的模型名称与原始服务商的模型标识对应起来，确保请求能正确路由到目标模型，从而更好地控制使用成本。

五大核心能力：Agent工作流的骨架

这份教程真正有价值的部分，在于系统拆解了 Agent 的五个核心概念。理解它们，才能明白「为什么 AI 做着做着会跑偏」以及「什么时候该开新的上下文」。

Tools：智能体的「手脚」

Tools 是智能体真正动手干活的能力接口。分析题目用 read，创建修改代码用 edit 或 write，运行测试用 bash。作者强调，关键不在于工具多，而在于「大模型自己决定什么时候调用哪个工具」——这正是智能体区别于传统脚本的核心。

从技术实现上看，智能体的工具调用依赖于大语言模型的function calling机制。这项技术由OpenAI在2023年6月首次引入GPT-3.5/4 API，随后被Anthropic、Google等厂商广泛采用。其工作原理是：开发者预先定义一组函数的描述（包括名称、参数、用途），以JSON Schema格式提供给模型。模型在推理过程中根据当前任务需求，自主决定是否调用某个函数以及传入什么参数。模型本身并不执行函数，而是输出一个结构化的调用请求（如 {"name": "read_file", "arguments": {"path": "problem.pdf"}}），由外部运行时环境（runtime）实际执行后将结果返回给模型。这种「模型决策 + 外部执行」的架构，使得语言模型能够突破纯文本生成的限制，真正与外部世界交互——读写文件、执行代码、访问网络、操作数据库等。值得注意的是，工具调用的可靠性很大程度上取决于函数描述的质量——描述越清晰准确，模型选择正确工具的概率就越高，这也是为什么Claude Code等产品在内部对每个工具都做了精心的prompt engineering。

Hooks：强制执行的「触发器」

如果说 Tools 是手脚，Hooks 就是工作流里的触发器——当某个事件发生时，自动执行一段预先规定的逻辑。

作者举了一个精妙的例子：若没有 Hooks，你让 AI「修改代码后一定要运行测试」，AI 可能遵守也可能某次忘了；但配置成 Hooks 后，这件事就一定会执行。Hooks 的核心价值在于约束 Agent，让不该等 AI 想起来才做的事强制稳定执行。

Hooks（钩子）的概念在软件工程中有着悠久的历史，最早可追溯到操作系统中的中断处理机制。Git本身就内置了pre-commit、post-merge、pre-push等十余种钩子机制，允许在特定操作前后自动执行脚本（例如在提交代码前自动运行代码格式化工具Prettier或静态检查工具ESLint）。在CI/CD（持续集成/持续部署）领域，Webhook同样是触发自动化流水线的核心机制——当代码推送到GitHub时，Webhook自动通知Jenkins或GitHub Actions启动构建和测试流程。将Hooks引入AI Agent工作流，本质上是把软件工程中成熟的「事件驱动」（Event-Driven）模式应用于AI行为管理。这解决了大语言模型的一个固有缺陷：概率性遵从指令。由于LLM的输出本质上是基于概率分布的采样（sampling），即使在系统提示（system prompt）中明确要求某些操作，模型也可能在某些情况下因为注意力分配变化或采样随机性而跳过。Hooks将这种「软性要求」转化为「硬性约束」，确保关键流程节点的确定性执行。在数学建模场景中，典型的Hooks配置包括：每次代码修改后自动运行测试、每次生成图表后自动保存到指定目录、每次模型训练完成后自动记录超参数和结果指标等。

Skills：专业的「操作手册」

Skills 解决的不是「AI 能不能做」，而是「AI 应该按什么方法、什么步骤、什么规范去做」。作者将自己整理的建模流程封装成了包含 15 个步骤、136 个子模块的 Skills 库，涵盖问题分析、数据处理、模型选择、优化预测评估，甚至包括获奖概率评估。

从技术角度看，Skills的实现通常依赖于系统提示（system prompt）或外挂知识库的机制。在Claude Code的架构中，Skills可以理解为一组预定义的CLAUDE.md文件或项目级配置，它们在Agent启动时被加载到上下文中，作为Agent执行任务的「操作手册」。这种设计与企业级AI应用中的RAG（Retrieval-Augmented Generation，检索增强生成）思路异曲同工——通过外部知识注入来弥补通用模型在特定领域知识上的不足。

针对「Skills 就是提示词换外衣」的质疑，作者给出了工程视角的辨析：提示词是一次性的任务指令，Skills 是工程化、模块化、可复用的任务方法。前者每次都要复制粘贴，后者可以封装成稳定复用的能力模块，二者在工程层面有本质区别。这种区分类似于软件开发中「临时脚本」与「封装好的函数库」的差异——前者解决一次性问题，后者通过标准化接口实现长期复用和持续迭代优化。进一步类比，一条提示词就像在终端里敲一行临时命令，而一个Skills模块则像一个经过测试、文档齐全、版本管理的npm包或Python库——它有明确的输入输出规范、有错误处理逻辑、有迭代更新记录，可以在不同项目中反复调用。

Subagent：临时叫来的「专业员工」

子智能体（Subagent）的核心价值在于上下文隔离。一个 Agent 若从头到尾独揽所有事，上下文会快速膨胀、注意力分散、出现幻觉。而子智能体让主智能体像「大管家」一样只关注任务调度本身，把搜集资料、验证方法等子任务委派出去，各自维护独立上下文。

这种设计理念源自多智能体系统（Multi-Agent System, MAS）这一人工智能经典研究领域，可以追溯到20世纪80年代分布式人工智能（DAI）的研究。MAS的核心思想是通过多个专门化的智能体协作来解决单一智能体难以处理的复杂问题，灵感来源于人类社会的分工协作模式。2023年以来，基于LLM的多Agent框架大量涌现：斯坦福大学的Generative Agents（2023年4月）通过25个AI角色模拟小镇社交行为引发广泛关注；MetaGPT（2023年8月）将软件开发的标准化流程（SOP）编码为多Agent协作协议；微软的AutoGen（2023年9月）提供了灵活的多Agent对话框架；CrewAI则聚焦于角色扮演式的Agent团队协作。这些框架的共同特点是让不同Agent承担不同角色（如产品经理、架构师、程序员、测试员），通过消息传递机制协调工作。上下文隔离是其中最关键的工程设计：每个子智能体只维护与自身任务相关的上下文，避免了单一Agent处理所有信息时的「注意力稀释」问题，同时也显著降低了API调用的token消耗成本——因为每个子Agent只需要携带完成其特定任务所需的最少信息量。

更进一步，还能实现能力隔离与权限隔离——例如让「阅读智能体」只能读代码提建议不能修改，「代码智能体」可以 read/edit/bash 但不能写论文。这种最小权限原则（Principle of Least Privilege）是信息安全领域的基本准则，在AI Agent场景下同样适用：限制每个子智能体的能力范围，可以有效防止Agent在自主执行过程中做出超出预期的危险操作。

不过作者也提醒了一个常见误区：并非智能体越多越好。20 个智能体可能导致循环调用、上下文传递混乱、结果汇总的重复劳动，甚至产生指令冲突。一个简单 bug，主智能体几分钟就能搞定，无需大动干戈。这一观察与软件架构中著名的「微服务陷阱」如出一辙——过度拆分服务反而会引入分布式系统的复杂性（网络延迟、数据一致性、故障级联等），有时一个精心设计的单体应用反而是更优解。

Context（上下文）：Agent的「短期记忆」

上下文是贯穿以上四项能力的隐性基础。基于Transformer架构的大语言模型在处理文本时，核心机制是自注意力（Self-Attention）：模型需要对输入序列中的每个token与所有其他token进行注意力权重计算，以理解token之间的语义关系。这意味着注意力计算的时间和空间复杂度随序列长度呈二次方增长（O(n²)）——当序列长度翻倍时，计算量增长四倍。虽然近年来出现了多种优化方案（如Flash Attention通过内存访问优化加速计算，或Sliding Window Attention通过限制注意力范围降低复杂度），但模型能「记住」的信息量仍然存在硬性上限。以Claude 3.5 Sonnet为例，其上下文窗口为200K tokens（约15万个中文字或30万个英文单词），而GPT-4 Turbo为128K tokens，DeepSeek-V3为128K tokens。

当Agent执行复杂的数学建模任务时，读取的题目文件、生成的代码、运行的日志、中间推理过程都会不断消耗上下文空间。一旦上下文接近饱和，模型会出现「注意力稀释」现象——这在NLP研究中被称为「Lost in the Middle」问题（Liu et al., 2023），即模型对长文本中间部分信息的回忆能力显著弱于开头和结尾部分。当关键的建模约束条件或数据描述恰好处于上下文的「记忆盲区」时，Agent就可能做出与题目要求不一致的决策，产生幻觉（hallucination）或逻辑不一致。理解上下文窗口的这种局限性，才能明白何时该拆分任务、何时该启用子智能体——这是高效使用 Agent 工作流的底层认知，也是判断「什么时候该开新的上下文」的技术依据。实践中的经验法则是：当单次对话的token消耗超过上下文窗口的60-70%时，就应该考虑开启新的上下文或委派子智能体，以确保模型的推理质量不会因信息过载而显著下降。

一站式集成工具：降低实战门槛

对于觉得「安装这么多软件太麻烦」的用户，作者推荐了一款集成化的「学术房」工具，它把 Git、VS Code、Claude Code 的配置都预先完成，并内置了提示词配置器、多种高级模型、论文查重和 AI 率检测功能。

该工具提供两种执行模式：

• 一键生成：全程无需干预，适合平时小作业的自动化处理
• AI 协作：可与 AI 实时交互下命令，适合国赛这类重要赛事

界面将建模手、代码手、论文手拆分为三个智能体卡片，队长控制台统筹全局，代码、图表、数据实时可见。这种角色化的多Agent界面设计，直接映射了数学建模竞赛中传统的「三人分工」模式——通常一个队伍由建模手（负责数学模型构建与分析）、编程手（负责算法实现与数据处理）和写作手（负责论文撰写与排版）三个角色组成。将人类团队的分工结构映射到AI Agent的协作架构上，既降低了用户的认知负担，也使得人机协作的边界更加清晰。此外还有团队协作功能，可以查看队友的工作进度——用作者的话说，「就能看到究竟是哪个同学在摸鱼」。

理性看待：工具红利与学术边界

这套工作流展示了 AI Agent 在专业场景落地的巨大潜力：从「问答工具」进化到「自主执行的协作伙伴」，确实能大幅提升数学建模效率。对于工程实践而言，理解 Tools、Hooks、Skills、Subagent 的分工协作，是驾驭现代 AI 编程工具的通用能力，远比背诵提示词更有长期价值。

但也需清醒地看到边界。视频中反复提及「降低 AI 率」「降低 AI 味」「降低重复率」以及国赛的「人工智能工具使用声明」，恰恰折射出学术诚信的敏感地带。事实上，自2023年ChatGPT引发全球关注以来，各类学术竞赛和学术期刊都在快速更新其AI使用政策。2024年全国大学生数学建模竞赛组委会已明确要求参赛队伍在论文中如实声明AI工具的使用情况；国际顶级学术期刊如Nature、Science也相继出台政策，要求作者披露AI在研究和写作过程中的参与程度。与此同时，AI生成内容检测技术（如GPTZero、Turnitin的AI Detection功能）也在快速发展，但这些工具的准确率仍存在争议——误报和漏报并存，特别是对于经过人工修改的AI生成文本，检测效果大幅下降。这场「生成与检测」的博弈，短期内不太可能出现一方完胜的结局。

当 AI 能够端到端产出论文时，如何界定「辅助」与「代劳」，如何在规则允许范围内使用工具，是每位参赛者必须审慎对待的问题。从教育的本质出发，数学建模竞赛的核心目标是培养学生的问题分析能力、数学建模思维和跨学科协作能力——如果这些能力的习得过程被AI完全替代，那么即便获得了奖项，学生也失去了竞赛本应带来的成长价值。

技术能力的跃升不应以学术诚信为代价——这或许是这套「爆肝终结者」工作流带给我们最需要冷静思考的一点。

核心要点