Feature增加
2026-03-10 支持Undo
这样可以保证Agent可以随便猜测
2026-03-11 支持结构体扫描和gap成员插入
借鉴HexRaysPyTools的思路，支持对着一个variable扫描并创建struct
2026-03-16 通过hook让mcp server知道是哪个agent调用过来的
调研了一大圈，mcp目前完全无法感知到不同的agent，ida pro mcp所谓的isolated contexts也只是在多个claude之间进行分离。
所以只能通过hook的方式，从hook的回调里面拿agent的信息（甚至就连hook里面的agent id信息也是后续才加上的）
通过hook，将agent id动态注入到mcp tool的input里就行了
思考
要不要采用fork-合并这种方案？
- 实现难点：如果采用这种，则需要两侧配合
- 需要引导subagent自主进行fork
- 需要主agent正确处理merge逻辑
- merge也需要考虑怎么实现：
- teams的merge需要保存idb，大binary的速度非常慢
- 或者直接简单replay？但是两个改了同一个函数怎么办？
- 是不是可以弄一个transaction概念给subagent？
- 完成后自动commit，但是怎么commit呢？
- 要不要弄一个额外的自动merge？
- 那这个其实还是fork-合并方案的小优化，还是需要考虑好怎么来合并
- 其实可以做一些简单的检测
- 检测操作有没有冲突，没有冲突再合并
- execute_python不能合并
- 增加类型可以
- 改不同地方的可以
- 改相同地方的不能合并
- 最终决定：fork - 合并方案，结合简单冲突检测
会话管理怎么做
- 现在的会话管理非常朴素，所有的agent共用一大套registry，通过随机sessionid来指定具体绑定到哪个session
- 模型经常记不住session id
- 模型也经常意识不到session概念的存在
- subagent还是完全意识不到自己在和parent用同一个idb，会互相抢
- subagent完全无法理解撤销这个步骤
- subagent甚至连主动进行idalib_switch都很难想到，导致session没有bind
- 其实没有必要让agent每次都idalib注册一次
- 目前的skill里面超过30%的篇幅仅仅是介绍idalib_的这些功能
- 方案1：每个subagent直接独立一个
- 或许在mcp检测到处于subagent中时自动就fork一个出来？
- 这样的话清理怎么办？
- 或许可以subagent主动调用清理的时候commit回去？
- 方案2：区分读写subagent，读的复用session，写的直接过
- 问题：目前完全依赖主agent来协调不同的agent是读还是写
调度怎么做？
- 需求：我们需要让AI能完整的逆完整个程序，而不是一小片，或者只有最顶上几层
- 如果让ai从入口点看，那ai经常过几层就停了，怎么解决
- 如果让ai从导入、导出函数来看，那显然也不太通用
- ai也并不喜欢来回反编译，反编译也不应该让agent疯狂调用decompile来实现
- ai现在的能力主要还是针对文件，所以能不能直接让他像读文件一样读代码？比如自动展开、局部读取之类的
- 方案1：不做调度，模型想干什么干什么
- 方案2：进一步细粒度化，按照function为粒度来协调subagent
- 要不要基于dirtree来协调不同的subagent？每个subagent只能改自己申请到的函数
- 或者没必要独占？是不是可以让所有的subagent共享一部分数据平面，这样他们后面碰到的时候可以互相问
- 这样的模式和每个agent写注释实时共享有什么区别？
- 如果共享了，又会不会污染上下文？
- 或者是说让他们并发跑， 然后最终的结果留给一个独立的merge agent来决定怎么合并？
- 方案3：让模型像操作文件系统一样操作反编译
- 好处：可以复用claude/codex的文件处理工具（grep等）
- 每次decompile之后，把结果写到文件系统里？
- 是写到同一个文件，还是写到每个函数一个文件？
- 文件名写什么？
- 怎么在调用后继续触发读文件tool？
- 问题：
- 需要让模型理解这东西是只读的
- 这东西是不是可能会outdated？
深入思考：或许可以参考软件开发的概念
- 现在的agent范式：
- subagent - worktree
- 主worktree/分支只用来接受PR
- 主agent负责协调subagent，以及处理冲突
- 对应到我们这边：
- subagent - fork session
- 主worktree只用来接受commit
- 区别：
- 源码是非常易于merge的， 但是在ida这边，merge是一个极大开销的操作
- 我们需要自己维护一套commit history
- 对策：
- 我们应该从源头上避免它们修改同一个函数，上面说的按照function调度之类的或许是一个好办法
- 问题是，要怎么让他们通讯，teammate互相发message的形式非常不合理，claude session一旦丢失，所有team mate也都没了，并不适合长期运行
- 我们或许得思考，为什么在逆向的时候会发生冲突
- 首先我们假定，他们不是因为从同一个位置出发而发生冲突的（因为这样的话属于调度异常）
- 情况1：两个agent都碰到了工具函数，那其实他们没有本质的冲突，只是应该合并他们的知识到数据库，并提醒后来者前面的人已经分析过这个函数
- 情况2：两个agent在模块边界相遇了， 那么就需要确定这个函数到底属于哪个模块
- 那问题来了，如果先来的agent的结果其实并不好，后来的agent要听吗？
- 怎么才把一个function归到一个模块里？ 是agent走到了就算？还是agent move到folder了？
实现方式的思考
- 问题：上面的功能说起来轻巧，实现起来却非常麻烦，如果自己写，那基本上就需要依赖rikugan，claude的很多优势功能就利用不上。
- 思路1：魔改rikugan，然后把ida mcp接起来
- rikugan的代码非常简单，而且项目迭代太快，难以同步
- 思路2：claude agent sdk
- 优势：可以自己加tool，可以关闭内置tool
- 缺点：需要自己做ui
- 思路3：claude code cli
- 如果要用原版claude实现，那就需要一大套东西
- 首先是mcp，如果要拿session id、agent id，那就必须走http
- 还需要有第二个mcp，通过stdio来保活告诉server这个session还活着
- 还需要有hook，如果要做subagent启动后自动fork session，那也需要相应的支持
- 还需要有更多的hook来支持各种调度
测试指标思考
- testcase选择：
- 基础：typed fixture
- 重算法
- 重逻辑+结构
- 高优化
- 重rpc
- 量化优化目标：
- 轮数更少？
- 错误率？
- 操作次序（类型
- 成品接近程度
- 先找出最优操作路径？
Agent内部思考
- 是不是可以实现一个足迹系统，每个ai过来的时候把自己的思考写到对应函数的node里（不是注释（这样方便我们更新）？
- 这玩意有用吗
- 怎么防止ai来回跑了好几次，每次都留了一次足迹？怎么让同一个agent留下来的足迹自己覆盖掉（通过session id 和agent id？）
- 怎么分agent？
- 专门分一个agent来进行类型修复？
- 还是重命名和类型恢复放一起？
- 还是把结构体恢复单独封出去？
- 常见的需要修复的类型
- 函数参数个数
- 局部变量类型（数组）
- 结构体重建（仅骨架）
- 返回值