用GLM接入Claude Code构建Infra Agent:实测RSI量化分析全流程

发布时间:2026/10/3 4:16:57
用GLM接入Claude Code构建Infra Agent:实测RSI量化分析全流程 上周末我干了一件有点叛逆的事把 GLM 接进了 Claude Code 当“外援模型”然后让它以 Infra Agent 的身份去研究一个叫 RSI 的量化指标——不是背概念而是真的像一个基础设施工程师那样从拿数据、写脚本、算指标、画图到输出报告把一整条链路跑完。结果有点出乎意料它不仅把活干完了还在我自己都没来得及提醒的地方除零、缺失时间戳、初始值对齐主动做了防御性处理。那一刻我的第一个反应不是“真厉害”而是后背发凉——Infra 被替代可能真的不远了。这篇文章就是这次实验的过程记录。我会讲清楚我为什么用 GLM 当 Agent、RSI 这个任务是怎么拆解的、agent 实际执行时做了什么、我在旁边核验了什么以及我最真实的判断什么样的 infra 工作会先被吃掉什么样的暂时还吃不掉。同时把期间踩过的坑cc switch 配置、thinking budget 调参、RSI 初值陷阱一并整理出来。无论你是做基础设施、做量化数据分析还是单纯好奇“AI Agent 到底能不能干活”这篇都值得看完。1. 为什么要拿 RSI 来考一个 Infra Agent1.1 Infra 工程师的日常比你想的更“脚本化”外人眼里的基础设施工程师是做高可用架构、搞负载均衡、设计容灾方案的人。但真正干过这行的人都明白一天里至少一半时间在做的事情其实特别“碎”帮业务看看某个接口延迟为什么周期性变高、抓一堆日志然后写个 Python 脚本统计错误码分布、把某个监控指标拉出来算个 p99、给新环境写配置、顺便清理一下没人知道是谁创建的定时任务。这些事情有个共同特征目标明确、边界清楚、可被自然语言描述。翻译过来就是——它们恰恰是最适合丢给 AI Agent 干的那类活。我当时想找个任务来测试这个判断RSI 就特别合适。它不是一个“写个 Hello World”级别的玩具题也不是一个需要领域专家级判断才能入手的难题。它就横在中间有公式、有实现、有脏数据、有边界条件、还要出图表和文字结论正好是 infra 日常里最常见的“数据分析小项目”的浓缩版。1.2 Infra Agent 是什么和普通聊天机器人有什么区别很多人用过 GLM 官方出的 VS Code 插件觉得“能在 IDE 里聊天补全挺方便”。但那是交互式辅助不是 Agent。真正的 Agent 是带着工具在跑的它能执行 bash、读写文件、调用 Python、访问网络然后在一个循环里不停“思考→行动→观察→修正”直到目标完成。这已经很接近一个拿着终端的新人工程师了只不过它的反应速度是秒级的而且不知疲倦。把 GLM 接进 Claude Code 之后它获得的就是这套工具链。社区里一个叫 cc switch 的小工具可以快速切换底层模型把 Claude Code 原来的模型替换成 DeepSeek、Qwen 或者 GLM。我试了一圈之后GLM 留了下来——下文会细说为什么。总之这次实验的主角不是一个“聊天窗里的 GLM”而是一个“能自己操作电脑的 GLM Infra Agent”。1.3 模型选型为什么是 GLM其实不是没试过别的模型。DeepSeek 和 Qwen 我都接入过各有各的好。但做 infra 类任务有个特殊要求既要代码能力又要工具调用的稳定性还要便宜到可以长时间挂着跑。GLM 的性价比在这个场景里很突出尤其 glm-5.3-flash-thinking 这种带“thinking budget”参数的新型号——你可以显式控制模型在回答前做多少“思考预算”。这个参数非常关键。预算调太高模型每一步都反复推理结果当然更稳但速度慢、token 消耗翻倍调太低它就容易不检查直接输出典型症状是“代码跑了能出图但逻辑是错的”。我做 infra 探索时一般把预算放在中高档位因为基础设施类任务最怕的不是慢而是“看起来对、实际上错”。另外 GLM 的 API 是可以在智谱开放平台单独买 token 的注册后创建一个 API Key、充点钱就能用按量计费不用买整包套餐。对于想低成本跑 Agent 实验的人来说这一点很友好。到了 GLM 5.4官方又在工具调用的稳定性上做了不少优化如果有条件可以优先尝鲜。2. RSI 不是重点重点是任务拆解2.1 先说清楚 RSI 是什么RSI 全称 Relative Strength Index相对强弱指标是技术分析里的老牌指标。它衡量一段时间内价格上涨幅度与下跌幅度之间的力量对比取值范围在 0 到 100 之间。常用参数是 14 个周期计算步骤大致是先求每个周期收盘价的涨跌量分别取正涨幅和负跌幅再用 Wilder 平滑法算出平均涨幅和平均跌幅最后套公式 RSI 100 - 100 / (1 平均涨幅 / 平均跌幅)。实际使用中RSI 大于 70 被普遍视为超买小于 30 视为超卖。听上去不算难但对一个 Agent 来说真正的挑战根本不在公式而在数据时间戳有没有对齐、有没有重复、最后几行是不是缺数据、某段行情如果一直横盘导致平均跌幅为 0 怎么办。这些才是区分“玩具实现”和“能上生产环境实现”的分水岭。2.2 我把任务拆成了五个子项为了让实验有可比性我把“研究 RSI”拆成五个明确的子任务然后一次性丢给 Agent数据准备读取我提供的 CSV 行情数据包含时间、开高低收、成交量先做基础探查。数据清洗识别并处理重复时间戳、缺失值、异常跳变并解释你做了什么处理及原因。指标计算用两种方式实现 RSI(14)交叉验证结果是否一致保留其中更合适的一个。可视化验证画一张叠加图包含收盘价和 RSI并标出 70/30 阈值线指出当前的最新状态。结论输出用一段人话总结数据所处的行情状态给出至少一条可执行的后续建议。这个拆法本身就是一份标准的 infra 工单。真实工作中业务方不会告诉你“把数据洗一下然后算个指标”他们只会说“帮我看一下这个指标为什么最近总是异常”。Agent 要做的就是把模糊的问题变成具体的子任务再逐个击破。我故意在 CSV 里埋了几处脏数据就是想看它能不能自己发现。2.3 设计提示词时埋的三个“陷阱”我给的提示词里埋了三个陷阱都来自真实 infra 场景的常见坑。第一个是脏数据CSV 里我故意留了一个重复时间戳还在文件末尾删掉了最后三行中的两行字段。如果 Agent 只会无脑pd.read_csv()然后直接算指标它不会崩但结果必然是错的。第二个是“用两种方式实现并交叉验证”的要求这能逼它展示对算法细节的理解而不是背一段网上常见的代码。第三个是“遇到不确定的地方先说明再行动”考察它在没有人类确认时是停下来还是硬猜。这三个陷阱都是日常 infra 里真实存在的。生产环境的数据永远比文档里讲的丑你永远没法指望输入是干净的Agent 如果不懂得停下来提问那它写出来的自动化就越危险。3. 实操过程实录从零到 RSI 报告3.1 五分钟把 GLM 接进 Claude Code这一步不算复杂但确实是很多新手卡住的地方。先把 Claude Code 装好然后装 cc switch用它创建一个指向 GLM 的 provider 配置。cc switch 本质上是帮你管理 Claude Code 的环境变量把默认的模型地址和密钥替换成 GLM 的。配置大致长这样{ providers: [ { name: glm, api_key_env: GLM_API_KEY, base_url: https://open.bigmodel.cn/api/paas/v4, model: glm-5.3-flash-thinking } ] }创建好 provider 后在 cc switch 里执行cc-switch use glm切换到该配置再启动 Claude Code它就会把请求发往 GLM 的 API。不用 cc switch 的话手动导环境变量也是一样的效果ANTHROPIC_BASE_URL指向 GLM 的兼容地址ANTHROPIC_AUTH_TOKEN填你的 GLM API Key再显式指定ANTHROPIC_MODEL为模型名。首次启动时 Claude Code 会询问是否允许它执行 bash、读写文件等操作。这一步很重要如果选了不允许Agent 后面会反复卡在“没有权限执行命令”上体验很差。既然要测它的 Infra 能力我选择放行 bash、文件读写和网络请求把变更类的高危操作留成每次确认。3.2 Agent 的执行轨迹我盯着它的执行过程看了大概四分钟整个过程值得记录下来。第一步它先读取了 CSV 的头部和基本信息打印出形状、列名、数据类型。然后没有急着算指标而是自己调了duplicated()检查重复时间戳——发现了那个我埋的坑并主动打印了一句“发现 1 个重复时间戳保留最后一条”。接着它检查了末尾缺失值发现最后两行有空字段补了一句“尾部存在缺失向前填充后用最近值补齐”。第二步它写了一个 RSI 计算函数用的是 pandas 的ewm做法。在我要求“两种方式交叉验证”之后它又写了一个经典 Wilder 递推版本把两种结果对齐输出。这里我看到了一个细节它对比后发现两个版本的前几个值有细微差别主动解释了差异来自初始平均值是用前 14 期简单平均还是直接从第一期开始递推并建议以 Wilder 版本为准因为这更符合业界口径。第三步它画图、标注阈值线、计算最新 RSI 值然后写了结论。结论里有行情状态判断有超买提示还给出了“建议等待回调或结合成交量确认”这种听起来挺专业的建议。整个链路没有一步需要我手动干预。3.3 我在旁边做的核验Agent 跑得快不代表它是对的。我在旁边做了一套人工核验这也是我认为 Infra 工程师真正不会被替代的那部分能力审查产出。我先用自己本地的一段行情数据跑了一遍另一套 RSI 实现对比了中间几个关键棒位的数值确认 Agent 的 Wilder 实现和我的结果一致。然后我专门问了一个边界情况如果有一段价格完全横盘平均涨幅和平均跌幅同时为 0你会怎么处理它回答自己的实现里会把 RSI 默认置为 100但承认这有争议很多行情软件在这种情况下会显示 50。当我说“改成 50”之后它立刻自己定位到除零分支并修改了代码还补了一个单元测试用例。这个细节挺让我感慨。它不是你让它改哪行它改哪行而是能理解“为什么要改”然后自己找到所有相关位置一并处理。这已经不像一个工具了而更像一个知道自己在做什么的初级工程师。但关键在于发现这个边界问题并提出正确主张的人是我。这大概就是未来几年人和 Agent 协作的基本分工。3.4 关键代码与参数Agent 最终采用的 Wilder RSI 实现是下面这种写法这里也分享给想自己跑一遍的人import numpy as np import pandas as pd def rsi_wilder(close: pd.Series, period: int 14) - pd.Series: delta close.diff() gain delta.clip(lower0.0) loss -delta.clip(upper0.0) # 用 Wilder 平滑alpha 1 / period avg_gain gain.ewm(alpha1 / period, adjustFalse, min_periodsperiod).mean() avg_loss loss.ewm(alpha1 / period, adjustFalse, min_periodsperiod).mean() # 全跌/全涨时限界处理 rsi 100.0 - 100.0 / (1.0 avg_gain / avg_loss.replace(0.0, np.nan)) rsi[(avg_gain 0) (avg_loss 0)] 50.0 # 横盘 rsi[(avg_gain 0) (avg_loss 0)] 100.0 # 全程上涨 return rsi如果你严格追求与行情软件一致初值处理上还要再加一层先取前 14 期做简单平均作为种子再递推。不过对绝大多数分析场景来说上面这段已经够用了重点是除零分支和横盘分支这两个最容易出隐蔽错误。另外我要求 Agent 把图表输出到一个 HTML 文件里。它用的是plotly收盘价主图叠加 RSI 副图外加 70/30 阈值虚线。我后面又追加了一个问题“按照 RSI 超过 70 卖出、低于 30 买入的规则做一次简单回测”它又自动把代码改造成循环遍历所有 K 线、统计交易次数和总收益率前前后后只多了两分钟。4. 从这次实验看 Infra 被替代的临界点4.1 五个让我惊讶的能力这次实验让我真正意识到威胁的是 Agent 表现出的五类能力。第一是工具链协调。读文件、跑 Python、装缺失的库、输出图表它全部自动完成没有一个动作是需要我补充指令的。第二是代码自检。第一次跑出来的图坐标轴变形了它自己发现并修正了 y 轴范围而不是把错图交给我。第三是领域常识。它能正确说出“RSI 大于 70 是超买”这种话虽然这是教科书内容但它能主动把教科书内容和当前数据结合说明常识检索和推理的衔接是通的。第四是防御性编程。除零分支、缺失时间戳、重复数据的处理它都做了。第五是沟通输出。它没有甩给我一堆代码而是给了一段结论清晰、建议可执行的报告。这五类能力叠加起来覆盖了大量 junior 到 mid-level infra 工程师的日常任务面。4.2 会被先吃掉的任务清单我不是说全行业明天就裁员但任务确实会按颗粒度排队被替代。以下是我根据这次实验和一些其他内部测试整理的清单任务类型自动化程度判断依据日志聚合与根因定位起草高读取日志、统计错误模式、生成疑似根因列表Agent 天然擅长监控告警规则编写高读文档、按模板生成 YAML、做规则校验完全符合 Agent 能力圈环境搭建与脚本编排高安装依赖、写部署脚本、执行并验证Agent 闭环能力强指标分析与报告输出高本次 RSI 实验就是典型一小时变成四分钟故障应急响应前排中Agent 能快速汇总上下文但跨系统的最终判断仍需人兜底跨团队沟通与变更评审低涉及组织政治和业务权衡Agent 现在做不到长期架构演进低需要战略判断和多年经验沉淀短期替代不了注意一个规律越能用自然语言清晰描述的任务越先被吃掉。“帮我把所有 error 日志按分钟聚合并画个趋势”这句话说清楚的那一刻活已经干了一半剩下的一半交不交给 Agent 只是成本问题。4.3 暂时还替代不了的部分反过来说有一些事短期内很难被替代。不是技术上做不到而是缺少“责任主体”。线上出了问题公司要的是一个人来承担责任而不是“Agent 建议的”。变更评审需要有人签字成本权衡需要有人向老板解释跨团队抢资源需要有人去开会。这些是组织行为不是技术能力。另外还有一个隐性资产叫“部落知识”比如某个遗留系统为什么当年那么设计、某个定时任务只有老人才知道不能动。这些东西不在任何文档里但 Agent 无法从代码里读出来。所以我的判断是Infra 工程师不会一夜消失但团队结构一定会变。过去是一个懂行的人带若干个执行者未来更可能是“一个资深工程师三个 Agent”的模式。资深工程师负责拆任务、定标准、做核验、背责任Agent 负责干那些重复且能被明确描述的活。4.4 我的真实判断说句心里话做完这个实验我焦虑了半天。因为我自己就是 infra 出身很清楚这种“数据分析小任务”在真实工作中的占比有多高。但焦虑过后我也意识到更准确的表达不是“Infra 被替代”而是“Infra 的手被替代了脑还在”。瓶颈不再是你能不能写出来而是你能不能想清楚要什么、能不能判断 Agent 给得对不对。这也解释了为什么最近社区里都在聊 Claude Code 这类工具的入门和第三方 API 接入技巧——大家已经在用脚投票把执行层的工作交给模型把人解放到判断层。5. 常见问题与避坑实录5.1 cc switch 与 API 接入问题先回答一个很多人问过的问题智谱 GLM 能单独买 API 的 token 吗能。到智谱开放平台注册账号、创建 API Key、充值然后按量付费使用不需要签什么大合同。拿到 Key 之后在 cc switch 里配置好 provider就能把这个 Key 用到 Claude Code 这种 Agent 工具里。有几个坑我替大家踩过了。第一是超时。GLM 的 thinking 模式如果推理步骤多响应时间会明显变长默认的 HTTP 超时常常不够用建议把超时调到 120 秒以上。第二是限流。并发请求太多会被平台限制cc switch 单开多个终端会话时尤其明显建议把并发窗口调小或者任务间隔里加适当的 sleep。第三是 thinking budget 这个参数。前面也说过了预算越高越稳但越贵越慢做 infra 探索任务我推荐中高价位做纯聊天或者简单问答可以拉低省钱又够用。另外有个容易忽略的点Claude Code 首次启动时的命令权限确认。你要是不允许它执行 bash它所有关于“我准备运行刚才写好的脚本”的操作都会失败整个 Agent 流程就卡死了。我第一次切换完模型就遇到过这个问题后来在配置里预先放行 bash 和文件读写就顺畅多了。5.2 RSI 计算本身的坑RSI 看似简单实际跑起来有不少版本差异。最典型的是初值处理经典 Wilder 方法要求先用前 14 个周期的涨幅跌幅简单平均作为初始平均之后再用递推公式而 pandas 的ewm(alpha1/period, adjustFalse)是从第一个值开始做指数平滑的两者前十几根 K 线的 RSI 会有细微差异。如果拿 Agent 的结果和券商软件对不上先查这个别急着怀疑算法错了。第二个坑是除零。平均跌幅为零的情况在强上涨行情里经常出现大多数实现把 RSI 置为 100。但如果一段行情完全横盘平均涨幅和平均跌幅都是零那就比较尴尬了有人置 100有人置 50严格说两个都是约定俗成。Agent 默认会选一种你得自己决定你接受哪一种然后最好在代码里明确写出来。第三个坑是周期口径。RSI 的 14 指的是最近 14 根 K 线的涨跌幅变化不是收盘价直接形成的 14 个点少算一根都不对。跨时区、停牌、缺数据都会导致时间序列不对齐rolling 窗口一错位后面全错。所以清洗数据时必须先把时间戳对齐再算指标顺序不能反。5.3 用 Agent 的四个习惯经过这次实验和之前若干次内测我总结出四个值得养成的习惯。第一个习惯是固定版本。把使用的模型版本、thinking budget、系统提示词全部记录下来最好一次性存进项目的 README 或者配置文件里。同一道题换一个模型版本或者换一个预算结果可能差很远没有版本记录你无法复盘。第二个习惯是要求引用来源。让 Agent 在给出结论时注明“这个口径来自某处文档”或“这个阈值是行业惯例”你会发现它能更谨慎少编造一些假信息。对 infra 场景来说来源不明的结论比没有结论更危险。第三个习惯是每次审查 diff。把 Agent 生成的所有改动当成一个同事提交的 PR 来 review。它写代码很快但你需要看它到底改了哪些文件、有没有顺手动了不该动的东西。这次实验里它的所有改动我都是逐个文件过了一遍才放心。第四个习惯是高危操作设置人工确认。涉及删文件、改生产配置、执行批量命令的操作一定要开着“请求人工确认”的开关。Agent 的意图通常是好的但它不会懂你生产环境的潜规则。5.4 怎么判断一个 Agent 能不能上生产最后分享一个我判断 Agent 能力的方法不要只看一个漂亮 demo拿一百个真实小任务去测它的成功率。统计它在一百个任务里有多少个是一次成功的、多少个修正后成功、多少个彻底失败。这个成功率就是你敢不敢让它上线的底气。我的经验是一个 Agent 的成功率不到七成之前只适合做探索和草稿不适合直接产出。到了九成以上就可以开始把它当半个正式员工用了但你还得保留“最终审查人”的角色。另外造脏数据测试也很有用。你可以在测试数据里故意加重复行、缺失值、异常跳变看 Agent 是会发现问题还是硬着头皮算完。这个测试在面试初级工程师的时候同样好用。我的体会是Agent 越来越像个能干但需要管理的近似全栈实习生而你的核心竞争力正在从“干得好”变成“管得好、验得准”。我个人现在的体会是跟 Agent 协作最重要的能力已经从“自己会写代码”变成“能说清楚要什么、能验证它给的答案”。那天的 RSI 图我留在了电脑上作为自己转型的纪念。也建议还在做 infra 的朋友找一个周末把 GLM 接进你的终端让它帮你复现一次你上周做过最无聊的那个数据排查任务。做完之后你再回来看这篇文章大概会明白我为什么后背发凉。