思考题： 按工具调用的数量，预先分配带确定长度的切片（Slice），然后通过传入索引 i 并发写入，这样既不需要加锁，又完美保证了最终的顺序匹配。 ``` results := make([]schema.Message, len(responseMsg.ToolCalls)) var wg sync.WaitGroup for i, toolCall := range responseMsg.ToolCalls { wg.Add(1) go func(index int, call schema.ToolCall) { defer wg.Done() result := e.registry.Execute(ctx, call) results[index] = schema.Message{ Role: schema.RoleUser, Content: result.Output, ToolCallID: call.ID, } }(i, toolCall) } wg.Wait() contextHistory = append(contextHistory, results...) ``` 顺着这个思路往下想，我觉得现实工程中“盲目并发”实在太理想化了，我有两点疑问： 疑问1：并非所有工具都能安全并发执行 大模型可能同时请求 FileRead、FileEdit、Bash 等操作。像读文件这类只读工具并发是安全的，但如果混入了文件修改或环境变更命令，无脑并发必然引发资源竞争和状态不一致。 我的思考：真正工业级的 Main Loop，似乎不能只用一个简单的 for 去并发所有动作。是否应该在 Tool 的定义里加入类似 isConcurrencySafe 的明确标识？不仅如此，调度器还要懂得“分区流水线”——遇到连续的安全工具就放到一批并发，遇到不安全的工具就截断退回串行，保证安全的基础上再去压榨并行效率。 疑问2：并发报错时的级联效应与循环打断问题 如果在并发执行的 5 个工具中，第 2 个工具报错了，我们是该死等其他工具跑完，还是立刻抛出终止信号结束本轮 Agent 循环？ 我的思考：一刀切的死等会浪费算力，但一刀切的中断又会摧毁本轮其他正常任务的上下文。是否在工业实现中，更需要一种“选择性的错误级联机制”？比如，通过 Context 控制子协程，如果有强依赖关系（比如连续的几个系统命令）其中一个错了，就取消关联的协程；但对于相互独立的操作（分别读取三个文件），其中一个报错不用阻断另一个，同时最外层的 Agent Loop 也绝不能因为某个工具操作失败而崩溃，而是应当将这些错综复杂的部分失败（Partial Failure）结果返回给大模型去自纠正。