用Deepseek驱动agentic全自动开发两个项目经验总结
两个项目、三种模型、四百块钱、五个agent、六天时间，无人全自动开发端到端应用。
起因是deepseek超级便宜的价格、和1M上下文带来的全新体验。让我我突然想到完全可以放开大胆的燃烧token。
加上在agentic实战局学习到了多agentic协作地各种架构、机制、以及思想，这些知识和经验让我从让多个agent讨论方案，进阶到了全自动开发的新坑之中。
在Anthropic之前的《harness-design-long-running-apps》文章启发下，我创新的增加了新的机制：
- 自进化（不断总结经验，并且根据任务卡片插入对应经验，解决了上下文过长问题）
- Wave/Track/Task 的进度管理方式
- 自动调度根据开发状态实现多agent的稳定编排。
一共尝试了两个项目：
- 帮我远程调式openclaw应用，让它能从我每天的笔记中提取迭代我的个人画像。
- 将原来的qunribao技能改造成了langgraph应用。
项目1的成功顺利实现，让我开始尝试更加复杂的项目2，并从中暴露出了更多的问题，并且进行了多次迭代后才形成了现在相对稳定的机制。
详情见：项目1：执行总结
介绍一下协作的机制：
烧了400块，迭代了n次。最终得到了如下的架构：
详细说明见：architecture-blueprint
目前来说是有一定进展的，一个还算合理的自进化、任务调度、agentic任务分工已经不断试错调整出来了。但是中间的调试过程遇到了很多难以解决的问题。
能力边界和问题：
这个过程中加深了对agentic交互的认知。box0这个项目的能力边界和运行原理。
- 当前的agentic通讯机制是直接应用的box0,它调度agent 用的都是claude code 的 -print 模式，权限比较高的同时、整个运转过程就是个黑盒。无法观测出具体问题是什么。agent在静默执行的时候，无法主动的结束自己的任务、并且记录关键问题所在。这个是很多问题产生的根源。
- box0功能限制：没有提供单独agent run的stop功能，导致必须完整的重启box0的后端才能终止进程。
- 长程运转受到规划能力的限制：能力上确实比单agent开发更加强大，但是在长程任务的规划上，缺乏经验，需要人类自己规划清楚这个任务的长度和边界。这个问题就导致了，无法判断清楚一个任务的开发难易程度单任务会超时、不清楚依赖人类的前置条件所以会卡死、对于限制条件也缺乏足够好的机制死守导致开发方向出现偏移...等等问题。这些都意味着agent无法执行过于长程和复杂的任务，于是系统陷入了无尽的任务拆分和无法主动停止的状态。
- 关于自进化机制的效益分析：在当前的协作机制下，经验会沉淀，可以避免出现重复出现一些问题，也能总结成功的路径。并且有分类能够智能的派送，解决了中小工程量开发任务的经验生产和消费的难题、以及上下文控制难题。但是存在一个问题，还是由于黑箱的agent和在当前进程下，无法继续之前的上下文，导致无法总结出真正的问题。这个会导致真正的问题没有暴露出来，外部审核agent一旦分析错误，就会把项目引向错误的方向。一旦陷入卡点，就会循环产出无意义低效益的经验（虽然有规避重复问题的机制）。
- 调度机制的选择：当前的机制依赖定时激活专门的调度agent分析开发进度，并且根据规则进行派发调度。那为什么最终选择定时激活调度agent，而不选择webhook的方式。核心原因是调度者不应被调度，否则会出现重复并发飞轮的灾难。
- 在开发效率上还有多问题：首先是调度agent 的激活corn设定，这个不能智能的根据任务开发难度来设定。然后是单个任务的超时时间设定。还有就是为了开发的稳定，需要增加审核agent，从而增加了token开销和时间开销。这些都是不同维度的决策问题。
- 关于人类需要参与什么的思考：agent并不能在所有的任务中给出合理的决策。经常给出“看似合理”但是逻辑上存在问题的答案。所以在许多问题上任然非常需要人工的介入。但是难度较大，整个过程没有清晰的观测指标，自动积累的经验人类阅读困难。导致不好了解介入时机。另一个就是，人类在规划的时候就得了解自己AI可能出现的边界，提前准备好必须要的资源。
展望下后续的迭代方向
- 解决核心的黑盒问题
- 增加上下文承接机制，让运转超时后能接续让builder分析问题所在
- 汇总需要必须人参与的部分
- 研究人与agenrtic系统协作的机制，除了对话窗口，还增加信号观测和管理机制。
- 灵活的模型路由,给不同的任务分发不同的模型。