为什么要做一个 iOS Bug 自动修复的 Agent 程序

一、为什么不直接做 IDE 插件

如果目标只是”在 IDE 里更方便地写代码”，那直接基于 CodeBuddy 这类 Agent IDE 做插件，通常更快、更省成本。

但我的目标不止于此：

把”修复/分析/定位/验证”沉淀成可复用能力
让 Agent 不依赖某个 IDE 才能工作
把人的经验流程产品化、平台化、自动化
围绕 iOS 问题定位、日志分析、修复建议形成领域能力

这些目标决定了我需要一套自建的 Agent 架构，而不是一个 IDE 插件。

二、自建 Agent 架构的核心优势

1. 掌握的是”工作流”，不是”某个 IDE 的扩展点”

基于 Agent IDE 做插件，本质上是在它既有能力上”加一层”。而自建 Agent 架构，本质上是在定义：

任务如何拆解
上下文如何收集
工具如何选择
失败如何回退
结果如何验证
多轮推理如何收敛

这意味着我拥有的是流程控制权。

这个差别很大：

插件模式：在别人的操作系统上写 App
Agent 架构模式：在定义自己的操作系统

未来我想做的事情——自动读取崩溃日志、自动定位可疑代码、自动生成 patch、自动跑校验、自动输出修复报告、自动接入 CI / 工单 / IM / 代码平台——自建 Agent 架构会比 IDE 插件自然得多。

2. 沉淀的是”领域智能”，不是通用编程助手能力

CodeBuddy 这类 Agent IDE 的强项是通用编码协作：补全、重构、对话式改代码、搜索代码、生成测试。

而我的系统围绕 iOS Bug Auto Fix 在做，重点是：

崩溃堆栈理解
符号/模块/调用链关联
Objective-C / Swift / Pod 生态理解
特定业务代码结构的定位
历史问题模式复用
修复策略模板化

这些能力，通用 Agent IDE 不会天然替我做好。我做 Agent 架构的真正价值不是”我也能调用 LLM 了”，而是：把特定领域的高价值决策流程封装成了 Agent。 这会形成自己的护城河。

3. 能做”非交互式自动化”，而不只是”人在 IDE 里点来点去”

IDE 插件天然偏向人在本地、打开工程、交互式提问、临场辅助。而自建 Agent 更容易扩展到命令行、批处理、服务化、CI/CD、机器人触发、定时任务、工单驱动修复。

未来完全可以做成这种链路：

1	崩溃日志/工单 → 问题归类 Agent → 代码定位 Agent → 修复策略 Agent → 生成 Patch → 验证 Agent → 提交 PR / 输出报告

这类能力，不是 IDE 插件的主战场。

4. 更强的”可解释性”和”可观测性”

自建 Agent 架构时，可以记录每一步：

为什么选这个工具
为什么判定这个文件相关
哪一步检索到了关键证据
哪次修复失败了
哪种策略成功率最高
每种 Bug 类型平均耗时多久

这带来几个重要价值：便于调试 Agent、便于持续优化 prompt / 工具策略、便于做质量评估、便于做企业内部合规审计。而很多 Agent IDE 内部流程只能”感觉它这么做了”，但很难完整掌控它的决策细节。

5. 模型、工具、供应商解耦

基于某个 Agent IDE 插件体系开发，通常会受到模型支持、上下文拼装方式、工具协议、权限边界、升级兼容性等限制。而自建 Agent 架构，可以自由决定用哪个模型、不同子任务切哪个模型、怎么做路由、缓存、检索、工具编排、降级和兜底。获得的是架构主导权，而不是平台适配权。

6. 能把”经验”复用到 IDE 之外

如果只是写成 IDE 插件，很多价值会被锁死在 IDE 内。但做成独立 Agent 能力，以后这些东西都能复用到 Web 界面、命令行、VSCode / JetBrains / 自研 IDE、Slack / 飞书 / 企业微信机器人、服务端 API、测试平台、发布平台、缺陷平台。投入更像是在建设能力中台，而不是做一个单点入口。

7. 更适合做多 Agent 分工

当任务复杂到需要角色分工时，自建架构优势更明显。可以拆成：

Agent	职责
Planner Agent	任务拆解
Retriever Agent	找代码和上下文
Diagnoser Agent	判断根因
Patch Agent	生成修复代码
Verifier Agent	运行验证
Reporter Agent	输出报告

IDE 插件当然也能”伪多 Agent”，但一般都会受限于宿主产品的交互模型。自建则可以真正把分工、状态、上下文边界、交接协议做清楚。

三、这条路的代价

1. 在重复造很多”基础设施轮子”

包括上下文管理、工具调用协议、提示词编排、重试/超时/回退、文件读写安全、结果验证、token 成本控制、观测和日志、会话状态管理。这些在成熟 Agent IDE 里很多已经做好了。短期看，肯定更慢、更贵、更累。

2. 需要自己为”效果稳定性”负责

自建后，要自己解决：为什么这次检索不到、为什么上下文污染了、为什么选错工具、为什么 patch 不可执行、为什么修复建议不稳定、为什么不同仓库表现差异大。获得自由的同时，也接管了复杂性。

3. 如果场景主要是”本地编码辅助”，ROI 未必更高

如果用户核心诉求只是在 IDE 里聊天、改改代码、顺手做点搜索、生成一些 patch，那自建 Agent 架构带来的收益可能并不明显。可能出现架构先进了，但用户体感未必更强的情况。

四、与通用 Agent IDE 的差异化定位

一句话定位

不是”更会写代码的 IDE 助手”，而是”面向 iOS Bug 定位、诊断、修复与验证的专用智能执行系统”。

差异对比表

维度	我的 Agent 架构	CodeBuddy / Cursor / Copilot Workspace
核心目标	解决特定领域问题（iOS bug 定位、分析、修复、验证）	提升通用编码效率
核心对象	问题处理流程	代码编辑过程
工作单元	一次完整的缺陷处理链路	一次对话、一段代码修改
触发方式	日志、崩溃堆栈、工单、CI、命令行、服务调用	IDE 内交互、选中代码、对话输入
能力重点	诊断、定位、决策、修复策略、验证闭环	补全、解释、生成、搜索、重构
领域知识密度	很高，内置 iOS/Crash/工程结构知识	偏通用，领域知识较浅
自动化深度	半自动甚至全自动链路	多数以人机协作为主
可观测性	记录每一步证据、推理、工具调用、成功率	通常黑盒程度更高
可扩展性	可接日志系统、工单系统、测试系统、CI、PR 流程	主要受限于 IDE 插件边界
平台依赖	独立能力层，不依赖单一 IDE	依赖宿主 IDE/平台生态
长期资产	沉淀为组织级问题处理能力	沉淀为某 IDE 内的使用体验
护城河来源	领域流程、知识、验证闭环、历史反馈	产品体验、模型集成、编辑器生态

五、哪些是真壁垒，哪些是在重复造轮子

判断标准

这个模块如果明天被一个成熟框架替换掉，我的核心价值会不会下降？

不会明显下降：大概率是基础设施

会明显下降：可能是壁垒层

真正值得重点投入的壁垒层

1. iOS 问题理解与归因知识

崩溃堆栈解析、符号/模块/类/调用链映射、OC/Swift 混编上下文理解、生命周期/线程/内存/KVO/通知/Block/主线程 UI 更新等问题模式、常见崩溃类型到修复策略的映射。这类能力沉淀好了，不是通用 IDE 随便能替代的。强壁垒。

2. 问题处理 SOP

稳定的处理链路：读取错误信号 → 归类问题类型 → 缩小嫌疑范围 → 关联代码上下文 → 选择修复策略 → 生成 patch → 执行验证 → 输出结论与风险。这个流程代表了团队如何排查问题、如何做决策分层、如何降低误修概率。强壁垒。

3. 修复策略库 / 模式库

沉淀 CrashType → RootCauseCandidates → VerificationSteps → PatchTemplate → RiskHints 这种结构。覆盖数组越界、空指针、野指针、线程竞争、主线程违规调用、通知/KVO 生命周期遗漏、容器并发修改、异步回调释放时序问题等。每一类问题对应典型特征、定位信号、修复范式、验证点。可复利的核心资产。

4. 验证闭环

改完代码后做静态检查、跑定向测试、检查编译影响范围、输出风险说明、对修复结果做置信度评估。从”助手”进入”执行系统”。关键护城河。

5. 历史案例反馈系统

积累哪类问题最常见、哪类修复策略成功率最高、哪些模块最容易出问题、哪种上下文组合最容易定位成功、哪类 patch 最容易被 reject。系统会越来越像”会学习的故障处理平台”。长期壁垒。

有价值但不要过度自研的中间层

模块	建议
任务拆解器 / Planner	可以做，但必须领域化，否则容易沦为通用壳子
多 Agent 分工	多 Agent 本身不是壁垒，领域化分工才是壁垒
上下文组装系统	保留策略，少造基础设施

大概率属于”重复造轮子”的部分

模块	建议
通用聊天壳 / UI 壳	够用就行
通用代码读写工具封装	稳定优先，不要过度精雕
通用 ReAct / Agent Loop	不要把”有 loop”误认为”有壁垒”
通用记忆系统	通用 memory 尽量轻，重点做 case memory
通用 Prompt 编排器	prompt 系统化可以有，但别把它当主产品

六、系统架构收敛

我把整个系统收敛成三层：

┌─────────────────────────────────────────┐
│              入口层（做薄）               │
│     IDE  /  CLI  /  CI工单  /  服务API    │
├─────────────────────────────────────────┤
│           领域决策层（持续加厚）            │
│  iOS缺陷分类 / 上下文选择策略 / 根因分析   │
│     修复策略选择 / 风险评估               │
├─────────────────────────────────────────┤
│           执行与验证层（够稳就行）          │
│  代码检索编辑 / Patch生成 / 构建测试       │
│     结果验证 / 报告输出                   │
└─────────────────────────────────────────┘

入口层：不要重投太多
执行与验证层：够稳就行
领域决策层：最该持续加厚的地方

七、最容易出现的风险

把大量精力花在让 Agent 看起来更像 Agent，而不是让它更会解决 iOS 问题。

典型表现：角色越来越多、prompt 越来越复杂、tool 越来越多、框架越来越完整，但定位成功率没上升、修复成功率没上升、验证能力没增强、真实用户价值不明显。

判断功能优先级时，统一用三个指标：

定位准确率是否提升
修复成功率是否提升
端到端处理时间是否下降

只要不能提升这三项之一，就谨慎做。

八、投入优先级

优先级	方向
第一优先级	把 `iOS bug 分类 → 根因 → 修复策略 → 验证` 做成稳定闭环
第二优先级	把历史案例沉淀成可复用知识
第三优先级	把入口做薄，支持 IDE / CLI / CI 复用
第四优先级	尽量复用通用 Agent 基础设施，不要在壳层卷复杂度

九、结论

我不是在做另一个通用 AI 编码助手，而是在做 iOS 缺陷处理的领域执行系统。

真正的壁垒不在 Agent 外壳，而在领域知识、决策流程、修复策略和验证闭环。

通用的对话、工具调用、Planner、Memory 更多是基础设施，应尽量复用而非重造。

后续投入应聚焦提升定位准确率、修复成功率和端到端效率，而不是继续增加通用 Agent 复杂度。

分水岭在于：我的系统是在”帮助程序员在 IDE 里更快操作”，还是在”替程序员执行一整套 iOS 问题处理流程”。答案是后者，所以自建 Agent 架构是正确的选择。

微言 | wyanassert
个人工作总结

为什么要做一个 iOS bug 自动修复的 agent 程序