还记得我们在第六章subagent末尾的提到的有向无环图吗？那时我们幻想让多个agent去分解一个大任务，那本章就基于这一问题的解决方案task_system。任务如何做持久化操作、A 做完了 B 才能开始，这层关系怎么表达，谁来检查、如何构建这种依赖关系、如何维护生命周期等等这些操作。本章，我们的任务是：1，从0开始构建整个任务分发系统。2，跑几个测试。整个任务分发有点像操作系统中死锁那一章节。

例如：还记得上一章末尾那个有关prompt的问题吗？紧接着本章就是在解决它。SYSTEM = (injected } \n" "Respect user preferences from memory.\n" "When the user says 'remember', extract it as a memory.\n" # ... 还在继续加)

第四章讲述了钩子，让agent_loop变得更整洁的操作。完整代码见我们的任务是：1，了解hooks，清楚hooks的重要性2，将s03的代码一步步重构为hooks3，感受引入hooks之后的模型交互过程还记得第三章末尾我遇到的问题吗？在真实环境中往往会编写一些日志函数去实时监控模型的工作状态，那监控有很多种，有的在调用结束时，有的在调用之前，如果我们想把这些都加进去，那整个agent_loop会

有没有遇到过这样的场景：当你vibecoding的时候，给模型下达一个任务，模型执行某一步时遇到问题，陷入寻找解决该问题的办法，忘记了自己一开始要干什么。这是因为主流的LLM基于Transformer架构，都面临注意力涣散的问题（注意和上下文窗口问题区分，放在最后总结了）。第五章讲述了todo_write，就是给agent列一个待办表，按照这个表去行动，期间也会不断更新这个表的操作。我们的任务是：

第二章，shareai讲述了给agent扩展工具的流程。完整代码见我们的任务是：1，扩展四个工具，手把手感受整个过程2，构建沙箱，了解沙箱为什么重要。3，感受claude code处理并发的操作那在写之前，我们需要先把os.getcwd()换成Path.cwd()，用WORKDIR去接收它，这么做的目的是方便后续工具把它作为全局变量使用，并且Path这个包还支持许多路径拼接，方便操作。现在来思考一

第三章，shareAI讲述了给模型加权限的过程。完整代码见我们的任务是：1，了解check_deny_list, check_rules, ask_user三道闸门组成的permission2，滤清楚权限检查的逻辑还记得第二章末尾提到，在run_bash中我们其实已经做过了一些权限检查，不过这只是象征性的，那样的硬检查对一些别有用心的shell语句几乎防不住，本章将一步步实现三层防护门，感受Cla

第六章开始事情变得有趣了起来，我们正式进入多agent的主题，前面五章全是一个agent在单打独斗，而真实的复杂的环境中往往需要多个agent协作来解决一个问题。就比如上一章节最后的时候，我们给agent单独跑了一个任务，但是发现整个执行非常慢。如果我们引入了多个agent，并发的处理多个不同的小任务，从而完成整个目标，是不是就会快了很多。当然，本章不涉及并发处理，仅仅介绍如何引入subagent

同一个api下，agent能力的差别取决于system prompt的构造。我感觉这句话自己写的太精准了哈哈哈，本章就是生动应用。试想一下，当你想把不同角色设定都塞进system prompt，那上下文直接爆了，而且其他不用的提示词会浪费很多token，因为计费是根据输入和输出token一块的。所以，本章尝试使用到某一提示词设定时，只将对应设定加载进去，然后做一个拼接。我们的任务是：1，实现ski

本章对Claude代码进行了重大修改，重点引入memory持久化策略来解决信息折损问题。主要改动包括：1) 清理冗余代码（如技能注册、待办功能等）；2) 基于s08版本构建记忆系统，实现记忆文件的读写、加载和管理；3) 新增记忆提取机制，从对话中识别关键信息保存到记忆文件；4) 简化了子代理工具集。最终系统能够将重要用户信息持久化存储，并在需要时重新加载到对话中，有效减轻了上下文压缩导致的信息丢失

有没有遇到过这样的场景：当你vibecoding的时候，给模型下达一个任务，模型执行某一步时遇到问题，陷入寻找解决该问题的办法，忘记了自己一开始要干什么。这是因为主流的LLM基于Transformer架构，都面临注意力涣散的问题（注意和上下文窗口问题区分，放在最后总结了）。第五章讲述了todo_write，就是给agent列一个待办表，按照这个表去行动，期间也会不断更新这个表的操作。我们的任务是：