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

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

数学建模比赛历来以「爆肝」著称——通宵读题、建模、写代码、调参、排版论文，一套流程下来往往需要三天三夜。而近期一位B站UP主「大师兄」分享的实战教程，展示了如何借助 Claude Code 和 Codex 这类代码智能体（coding agent），将整套数学建模流程交由 AI 自动完成。

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

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

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

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

Agentic coding 是2024年以来AI编程领域最重要的范式转移之一。其核心思想源自强化学习中的Agent概念——一个能感知环境、做出决策并采取行动的自主实体。在软件工程语境下，这意味着AI不再只是一个被动的代码补全工具（如早期的GitHub Copilot），而是演变为一个能理解任务目标、自主规划执行步骤、调用外部工具、并根据反馈迭代修正的完整执行系统。这种模式的技术基础是大语言模型的function calling（函数调用）能力和ReAct（Reasoning + Acting）推理框架，后者由普林斯顿大学于2022年提出，让模型在推理过程中交替进行「思考」和「行动」两个步骤。

像 DeepSeek、豆包这类对话工具，本质上是「只能回答却不能替你干活」的。用户提问，模型给出文本回答，仅此而已。而 Claude Code、Codex 这类代码智能体则是「专门为了干活而生的」——用户抛出任务后，模型会自主推理、决策，然后调用相应工具获取结果，再继续推理、再调用工具，如此循环直到完成任务。

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

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

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

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

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

Git：AI的「后悔药」

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

Git由Linux之父Linus Torvalds于2005年创建，最初用于管理Linux内核的分布式开发。在传统软件开发中，Git的核心价值是多人协作和版本追溯。但在AI Agent工作流中，Git扮演了一个全新角色：它成为了Agent自主迭代过程中的「安全网」。由于代码智能体会自主修改文件、运行命令甚至重构代码结构，一旦Agent在某次迭代中做出了错误决策（比如删除了关键函数或引入了破坏性改动），Git的分支（branch）和回退（checkout/reset）机制可以让用户瞬间恢复到任意历史状态。这种「可撤销性」对于AI驱动的自动化流程来说是不可或缺的安全保障——毕竟 AI 也会「跑偏」。

VS Code：可视化的操作台

VS Code 作为代码编辑器，配合官方的 Claude Code 插件，可以将黑框式的命令行操作转化为可视化界面，大幅降低新手上手门槛。

Claude Code / Codex：核心智能体

这是整套工作流的大脑。说个细节，OpenAI 的 Codex 已与 ChatGPT 合并，因此下载时显示为 ChatGPT 属于正常现象，并非出错。

对于国内用户，作者也给出了务实的方案：通过 CitySwitch 这类工具接入第三方模型 API（如 DeepSeek），绕开官方服务的网络与充值限制。API Key（应用程序接口密钥）是云服务中标准的身份认证机制，用于标识调用者身份并进行用量计费。在大模型服务领域，OpenAI、Anthropic、DeepSeek等厂商均通过RESTful API提供模型调用服务，按输入/输出token数量计费。第三方中转服务的工作原理是充当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等厂商广泛采用。其工作原理是：开发者预先定义一组函数的描述（包括名称、参数、用途），模型在推理过程中根据当前任务需求，自主决定是否调用某个函数以及传入什么参数。模型本身并不执行函数，而是输出一个结构化的调用请求，由外部运行时环境（runtime）实际执行后将结果返回给模型。这种「模型决策 + 外部执行」的架构，使得语言模型能够突破纯文本生成的限制，真正与外部世界交互——读写文件、执行代码、访问网络、操作数据库等。

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

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

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

Hooks（钩子）的概念在软件工程中有着悠久的历史。Git本身就内置了pre-commit、post-merge等钩子机制，允许在特定操作前后自动执行脚本（例如在提交代码前自动运行代码格式化工具）。在CI/CD（持续集成/持续部署）领域，Webhook同样是触发自动化流水线的核心机制。将Hooks引入AI Agent工作流，本质上是把软件工程中成熟的「事件驱动」模式应用于AI行为管理。这解决了大语言模型的一个固有缺陷：概率性遵从指令。由于LLM的输出本质上是概率采样，即使在系统提示中明确要求某些操作，模型也可能在某些情况下跳过。Hooks将这种「软性要求」转化为「硬性约束」，确保关键流程节点的确定性执行。

Skills：专业的「操作手册」

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

针对「Skills 就是提示词换外衣」的质疑，作者给出了工程视角的辨析：提示词是一次性的任务指令，Skills 是工程化、模块化、可复用的任务方法。前者每次都要复制粘贴，后者可以封装成稳定复用的能力模块，二者在工程层面有本质区别。这种区分类似于软件开发中「临时脚本」与「封装好的函数库」的差异——前者解决一次性问题，后者通过标准化接口实现长期复用和持续迭代优化。

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

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

这种设计理念源自多智能体系统（Multi-Agent System, MAS）这一人工智能经典研究领域。MAS的核心思想是通过多个专门化的智能体协作来解决单一智能体难以处理的复杂问题。2023年以来，基于LLM的多Agent框架大量涌现，如斯坦福大学的Generative Agents、MetaGPT、AutoGen、CrewAI等。这些框架的共同特点是让不同Agent承担不同角色（如产品经理、架构师、程序员、测试员），通过消息传递机制协调工作。上下文隔离是其中最关键的工程设计：每个子智能体只维护与自身任务相关的上下文，避免了单一Agent处理所有信息时的「注意力稀释」问题，同时也显著降低了API调用的token消耗成本。

更进一步，还能实现能力隔离与权限隔离——例如让「阅读智能体」只能读代码提建议不能修改，「代码智能体」可以 read/edit/bash 但不能写论文。

不过作者也提醒了一个常见误区：并非智能体越多越好。20 个智能体可能导致循环调用、上下文传递混乱、结果汇总的重复劳动，甚至产生指令冲突。一个简单 bug，主智能体几分钟就能搞定，无需大动干戈。

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

上下文是贯穿以上四项能力的隐性基础。基于Transformer架构的大语言模型在处理文本时，需要对输入序列中的每个token与所有其他token进行注意力计算，其计算复杂度随序列长度呈二次方增长（O(n²)）。这意味着模型能「记住」的信息量存在硬性上限——以Claude 3.5为例，其上下文窗口为200K tokens（约15万字），而GPT-4 Turbo为128K tokens。

当Agent执行复杂的数学建模任务时，读取的题目文件、生成的代码、运行的日志、中间推理过程都会不断消耗上下文空间。一旦上下文接近饱和，模型会出现「注意力稀释」现象：早期输入的关键信息被「遗忘」，导致后续决策质量急剧下降，产生幻觉（hallucination）或逻辑不一致。理解上下文窗口的这种局限性，才能明白何时该拆分任务、何时该启用子智能体——这是高效使用 Agent 工作流的底层认知，也是判断「什么时候该开新的上下文」的技术依据。

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

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

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

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

界面将建模手、代码手、论文手拆分为三个智能体卡片，队长控制台统筹全局，代码、图表、数据实时可见。此外还有团队协作功能，可以查看队友的工作进度——用作者的话说，「就能看到究竟是哪个同学在摸鱼」。

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

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

但也需清醒地看到边界。视频中反复提及「降低 AI 率」「降低 AI 味」「降低重复率」以及国赛的「人工智能工具使用声明」，恰恰折射出学术诚信的敏感地带。当 AI 能够端到端产出论文时，如何界定「辅助」与「代劳」，如何在规则允许范围内使用工具，是每位参赛者必须审慎对待的问题。

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