多agent 上下文交接的正确姿势是什么？

昨天才向gpt 讨教了multi agent不同协作模式的流转，今天就刷到佬了。插眼

我看了这个视频后改变了一些观点，由人显式处理多 agent 或许会更好些。

站内许多帖子都对 codegraph 持负面观点，看起来不是很有用。

这玩意现在是蓝海哦 目前好像没有啥成熟可靠的解决方案，靠你了

嗯嗯，我来学习一下这个视频看看有什么新思路，谢谢佬

我用的claude自带的teams功能，每次token消耗都爆炸，但是好的一点是可以切换subagent和他们独立对话

佬说的是agent view 么，codex 好像也有类似的。claude code 我跑卡死过子agent，而且它好像非要用git worktree 还收不干净。

看下 A\的Dynamic Workflow，我觉得还不错

review 的活感觉可以交给另一个agent，这个agent 只跟主agent 汇报最终的review 结果

然后主agent 只是派活儿跟进度

这个不还是和之前一样么，主agent说白了还是要读一遍目前子agent传给他的上下文，解析上下文才能跟进度和派活。

你想要token消耗少就只能给比较明确的workflow，让主agent尽量只是派活。

llm驱动任务的核心流程是，告诉它你有什么function_call ，怎么调用在它，它自己决定。传什么参数也是它自己决定，当然你可以通过提示词优化一下

有道理，这是个优化点的，主agent 的上下文得收敛，派活儿就得了。不然就跑不了长任务了。

我以前刷到过有人推荐邮件这样的形式 ^-^ ^-^

邮件感觉挺高级的~ 给每个agent 搞一个邮箱么~

目前我们是通过产物来交接的，token不用担心会有缓存，主要是产物的输出token会比较多，但是能接受，因为是很详细的设计，很有意义。补充下，是多agent。

不走主agent 中转，直接子agent 之间通过类似文件这种是么

是的，会有任务编排，产出结果比较满意。

总结了一下这个视频：

1. 
   

   先区分问题类型：低保真问题，比如“路由 URL 是什么”，适合在 grilling 会话里回答；高保真问题，比如“这个 UI 用起来应该是什么感觉”，需要原型或可视化验证，应该切到 prototype/handoff 会话再回来。

   
   


2. 
   

   控制范围：不要一次 grill 一个巨大功能。范围太大会引出太多隐藏问题，还会把上下文窗口塞满，进入模型表现变差的 “dumb zone”。更好的做法是先拆成小块，分别讨论。

   
   


3. 
   

   人要主动参与：你不能完全被动等 AI 问；要不断校准方向、收敛范围、判断哪些问题值得继续。反过来也别过度规划，到了能开写代码的时候就该停。

   
   


4. 
   

   别浪费讨论成果：一次 grilling 会话里积累了很多设计决策。不要清空上下文重新开始；如果还能继续，就直接实现。如果上下文快满了，就先整理成 PRD 或 handoff 文档。

   
   


5. 
   

   规划阶段要用强模型：grilling 依赖模型的“内在知识”和设计直觉来提出你没想到的问题，所以适合用更聪明的大模型；实现阶段如果上下文和计划足够清晰，可以用小模型。

   
   


6. 
   

   可以并行开多个 grilling 会话：一个会话在思考时，你可以切到另一个会话回答问题。作者认为多数人同时跑两个会话比较舒服，熟练后可以更多。

   
   

我们也是类似的策略，还有一些记忆和handoff的设置

是的，设计阶段可以干预修改，编排也可以修改，会形成一个比较专业的流程，结果不会偏离预期。