假设父 Agent 正在排查登录问题，前面已经确认两件事：这次只检查新版流程，上周旧版的故障不属于当前范围。它把一个子任务交出去，内容却只有一句：“检查登录问题。”
父任务知道版本，也知道哪些线索已经过期；接手的子 Agent 是否知道，要看这些信息有没有进入它的输入。给它起一个“登录专家”的名字，并不会把父会话的讨论一起带过去。
独立上下文能让分工更干净，也会切断隐含信息。如果交接只剩一个宽泛目标，接手者可能重新选择范围，甚至认真研究一个父任务已经排除的问题。
做多 Agent 项目，值得追到实现里的一问是：子循环启动时，第一条消息里究竟有什么？ 先把这个入口看清，再讨论它为什么能接住任务，以及它返回的内容能否支撑父任务继续工作。
新循环只收到一条显式输入
在这份本地 cc-python 实现里，父模型通过 AgentTool 派生子任务。工具接收任务 prompt，还可以指定模型和运行方式。它随后组装子工具集，进入一个新的 query_loop。
前台执行路径创建的初始消息很短：一个 UserMessage，内容就是传入的 prompt。这里没有把父循环的 messages 复制过去，也没有根据任务描述自动挑出父会话里的相关片段。
子任务使用的系统提示词也来自预设的 DEFAULT_AGENT_PROMPT，而非直接复制父任务的系统提示词。因此，父任务的完整讨论与本次子任务收到的行为说明，需要分别看实际传参。
回到登录排查，如果 prompt 里只有“检查登录问题”，新版范围和排除旧版故障这两个条件就没有通过这条消息传入。父任务在此前确认过它们，不能替代一次明确的信息交接。
源码中的后台路径同样从一个包含 prompt 的用户消息开始。前后台会改变等待和返回的方式，但不会因为切成后台，就自动拥有父任务的全部历史。
