1. 项目缘起为什么我会花10天用Claude硬搓一个“Manus”级别的Agent先交代一下背景。做AI应用开发的同行应该都有同感2025年Manus这股风刮起来后圈子里分成了两派。一派觉得这是“通用Agent元年”另一派冷眼旁观说这东西的本质就是大模型套了一圈工具调用和任务编排没有想象中那么神。我本人偏向后一派但同时又觉得——既然大家都说它没那么难那不如自己动手验证一下到底用现在的AI编程能力多久能搓出一个能看的替代品。于是就有了这个项目的起点用Claude当主力写码工具10天时间从零做一个类似Manus的通用任务型Agent取了个内部代号叫“小One”。项目最大的特点不是什么自研了某个多牛的技术而是全部代码包括后端、前端、Prompt逻辑、工具调度、数据库设计都是AI一行行生成的。我大部分时间做的是提需求、拆任务、让AI“自纠错”的工作。结果确实出乎意料第4天小One能完成Google搜索任务第6天它能爬网页抓取列表信息第10天它已经能处理一个完整的三阶段复合任务——查资料、整理数据、输出报告。整个过程里真正我手写的代码不超过200行基本都是函数签名和接口对接时的微调。提示这项目并不打算宣称“彻底超越了Manus”相反小One在中断恢复、实时交互、并发稳定性这些指标上差得很远。但它证明了另一件事——AI写代码已经不只是辅助了在充分拆解和引导下它可以独立撑起一个完整Agent项目的工程实现。这篇文章我会把整个项目的来龙去脉、系统设计、每天的开发进度、踩过的坑、以及用AI写代码时最重要的方法论全部摊开讲一遍。如果你是做Agent产品、对AI编程感兴趣、或者想评估“AI能不能替代程序员”的从业者这篇内容对你应该挺有价值。2. 核心思路与架构设计让AI写代码前提是你自己得想清楚系统骨架用AI写代码有个很反直觉的点越是要靠AI省力你越需要自己有清晰的系统设计能力。这不是玄学是实操中反复验证过的规律。AI能帮你生成几千行代码但它不会替你决定“这个系统到底该分几个模块”“任务状态机应该怎么流转”“工具调用的超时策略放哪里”。这些架构级决策AI只会给你一个“看起来合理”的默认答案但往往不是最适合你项目的答案。2.1 先拆Manus的核心能力想清楚什么东西是可以复刻的在做小One之前我把Manus的能力拆成了四层大模型的理解与规划层接收用户模糊的任务描述拆解出可执行的子任务清单。工具调用层包括浏览器操作、搜索引擎、文件读写、数据解析、代码执行等。状态管理层记录任务进度、中间结果、历史决策确保长任务不丢上下文。交互展示层把过程和结果以用户可读的形式呈现出来。这四层里只有第一层是真正依赖大模型“智能”的后面三层都是工程问题。工程问题意味着什么意味着不需要创新只需要正确实现。既然只是正确实现那么用AI写代码的可靠性就会高很多——因为这是最容易验证、最容易被测试覆盖的部分。难啃的反而是第三层状态管理。这也是我决定花大精力设计的原因。2.2 小One的系统架构我为什么选“单执行器多脚本工具”而不是多层Agent嵌套很多人做Agent容易陷入一个误区——把Agent搞得越“自动”越好多层嵌套、多Agent协作、动态生成子Agent。听起来很炫但用AI写代码的时候这种设计会变成灾难AI生成的多层调用链一旦出bug你排查的成本会成指数级上升。小One的架构走了另一条路单执行器核心 多外部工具脚本。核心思路主AgentClaude模型驱动负责理解和决策但它不直接操作浏览器、不直接写文件所有实际动作都通过调用独立的Python/Node工具脚本完成。主Agent输出的是“调用哪个工具、传什么参数、要什么结果”然后由一层非常薄的执行器去实际执行再把结果塞回大模型的上下文。这样设计的理由有三个AI写代码时单个工具脚本的确定性远高于复杂的嵌套逻辑。我可以让AI先写“Algolia搜索脚本”“网页正文提取脚本”每个脚本独立测试通过后再接入主流程出错时能快速定位。工具结果结构统一上下文清晰。所有工具的输出都会先转成统一的JSON结构截断后送回大模型避免大段HTML污染上下文。这种架构对AI编程最友好。因为每个模块的Prompt和代码生成任务都是独立的我可以逐个小步提交需求让Claude逐步生成而不是让它一次生成整个系统。2.3 关键决策我们选择“顺序执行器”而非“并行执行器”的真实原因在设计执行器时AI给了我两个方案顺序执行和并行执行。它推荐并行理由是效率高。我没有采纳原因非常实际——并行执行会让每个子任务的运行状态难以追踪一旦某个并行分支失败整个任务状态会变得杂乱而这种杂乱对AI代码来说是致命的因为AI从报错中学习时很难准确判断错误来自哪个分支。10天版本的最终选择是任务列表按依赖关系排序支持并行度设为1也就是单线程顺序执行。效率是慢一点但胜在状态一目了然任务到哪一步、哪一步失败、失败原因是什么都能精确定位。负责任地说顺序执行在真实使用中确实会慢但考虑到目标只是“验证可行性”稳定性优先级远高于性能。后面如果要做生产级并行执行器可以再加但现在这版够用。3. 10天开发实录从零到可用每天到底在干什么这部分是全文的重头戏。我按天拆解整个开发过程包括每天的具体目标、用到的Prompt思路、遇到的问题以及最终的产出。这也是很多读者最好奇的部分——10天到底是怎么做到的。3.1 第1-2天环境搭建与工具脚本打底前两天不急着写Agent主逻辑而是把所有工具脚本做完。这个决定后来被证明极其正确——因为AI写小工具脚本的完成度非常高很少需要改动而工具脚本就是你整个系统最底层的地基。我用Claude一口气生成了三个工具脚本searcher.py对接一个公开的搜索API接收查询词返回结构化结果列表标题、URL、摘要。crawler.py访问指定URL提取正文内容转成干净的Markdown格式。file_io.py读写JSON、Markdown文件用于保存任务结果和中间状态。这三段代码Claude基本都是一遍过我只在外面套了一层简单的异常兜底每个脚本都保证出口返回一个统一的{status, data, error}结构。这天的教训是写工具脚本时Prompt里必须明确输出格式要求。如果只说“抓取网页内容”AI可能给你返回HTML标签包着的一坨数据但如果明确说“返回去除HTML标签、保留段落结构的纯文本”质量就完全不一样了。3.2 第3-4天主Agent核心与Prompt框架搭建第三天开始进入核心部分——主Agent的决策循环。这一天的开发量最大因为要把大模型调用、工具调度、状态管理三块逻辑捏到一起。我让Claude先写了一个纯Python的主循环代码块逻辑非常朴素while not task_queue.is_empty(): current_task task_queue.next() response call_llm(current_task, context) action parse_action(response) if action.type TOOL_CALL: result execute_tool(action.tool, action.args) context.update(current_task, result) elif action.type OUTPUT: final_result.append(parse_output(response))这段代码里最重要的是Prompt模板的设计。我给Claude的指令是你是一个任务执行Agent。你需要分析当前的目标、当前任务列表、以及已有上下文决定下一步动作。你的可能动作只有两种调用工具searcher、crawler、file_io或输出最终答案。当信息不足时必须调用工具当信息足够时必须输出最终答案。禁止在没有工具支撑的情况下编造内容。这个Prompt模板非常关键它其实是一个“穷举法”式的决策边界把大模型的自由发挥空间压到最低。很多Agent做不好的原因不是模型不够聪明而是它太敢“自由发挥”了一旦让它觉得“我知道答案”它就懒得调用工具验证。这种“硬约束Prompt”的思路是整个项目最核心的操盘经验。第4天晚上小One完成了第一次完整的端到端跑通。我给它输入“搜索2024年全球AI芯片市场的三篇重点报道指出主要玩家”它花了7分钟调用了4次searcher抓了6个页面最后输出了一份粗糙但结构完整的报告。那一刻真实的感受是兴奋但没有想象中那么兴奋因为我知道后面的坑还多着呢。3.3 第5-6天前端展示与交互体验第五天开始做前端。这里我犯了一个典型的“AI编程新手”错误——我给Claude的初始Prompt是“做一个好看的任务展示界面”。这个需求太模糊了AI直接给我生成了一个花里胡哨的HTML页面全屏渐变背景、3D卡片翻转、粒子动画看得我哭笑不得。冷静之后我换了一种写法。我给了AI一个明确的参照系章节4会详细说Prompt方法论要求是以操作日志面板为核心的极简深色界面左侧为任务步骤列表按时间线展示右侧为“当前正在做什么”的大状态卡片以及最终结果输出区顶部有一个表单输入框用于提交新任务。这次生成的页面就正常多了。前端的核心价值不是炫技而是让用户看到任务进展保持“它在干活”的信心感这一点在我后续测试中得到了反复验证——一旦长时间没有反馈用户的第一反应就是“卡死了”。第六天接入前后端前端提交任务后端启动Agent执行前端通过轮询接口实时拉取任务步骤并渲染。因为前后端都是用AI生成的接入时的接口字段名不匹配问题反复出现我也是从这天真正体会到了“给AI提供接口契约”的重要性。3.4 第7-8天状态持久化与任务中断恢复第7天开始处理一个生产级Agent必须面对的问题任务跑到一半程序崩了怎么办Manus这类产品的一个重要指标就是任务可恢复性虽然小One是Demo项目但我不想做那种一断电就前功尽弃的玩具。我的方案是把所有任务状态、中间结果、上下文摘要全部写入SQLite数据库。每个任务节点执行前后都触发一次状态快照当前执行到第几步、已完成步骤的结果摘要、下一步待执行的参数。如果程序中断重启AI会根据数据库中记录的任务状态自动决定是从头继续还是从断点继续。这个方案本身不复杂但让AI写这一段的难度比想象中大因为涉及业务逻辑里最琐碎的状态判断——比如“已执行成功的步骤结果存在哪”“失败重试和跳过怎么区分”“上下文摘要怎么控制长度”。最后我采用了一种经验做法写不出一个完美持久化方案没关系先把数据库字段定下来让AI照着字段设计状态保存逻辑。数据库字段如下字段名类型说明task_idtext任务唯一标识task_goaltext原始任务描述current_stepint当前进行到第几步steps_donejson已完成步骤的摘要及结果context_blobtext压缩后的上下文供下一步决策statustextrunning/failed/successcreated_attext创建时间这天的关键心得是向AI描述数据表结构比用文字描述业务逻辑要高效一个数量级。AI对结构的理解能力远好于对模糊文字的“揣摩能力”。3.5 第9天系统联调与边界情况处理第9天没有新的功能开发完全在联调和修边角。当天处理了三个比较典型的问题搜索结果为空时Agent陷入死循环不断重新搜索同一个查询词。解决方案是给工具调用加了次数上限同一个查询词最多执行3次超过则强制Agent换一个搜索角度。长网页抓取后截断逻辑会让页面正文被切断到一半导致关键信息丢失。后来优化成“按段落截断”保证返回的最后一段一定是完整段落。某些工具脚本运行时会因为网络问题抛异常执行器捕获异常后直接把错误信息塞回LLM上下文导致AI误以为“搜索结果就是错误信息”并写进最终报告。这个很关键工具返回值必须严格区分“业务结果”和“系统异常”两套状态不能混在一个字段里。3.6 第10天Demo演示与性能测量第10天没什么好吹的就是打磨和测量。我用了一个标准的多阶段任务来测试小One任务“请搜索当前全球市值最大的5家科技公司获取它们最近一个季度营收写成一份对比报告。”完整用时21分37秒共调用了11次搜索API、13次网页抓取生成了约3000字的报告。报告的文字部分确实流畅卡片式的数据对比表格也自动生成得很好。第二天我把演示发给几个业内朋友看大家的反应基本符合预期一半人觉得“有点意思但这离Manus还很远吧”另一半人关注的是“这些代码真的是AI写的”——这个反应本身就是我想说的话题当“AI写代码”这件事的完成度首次突破某个临界点业界的反应往往不是狂喜而是本能的怀疑。4. 让AI写代码的真正门槛不是技术是需求拆解能力和Prompt纪律如果这篇文章只留下一个核心观点那我希望是这句让AI写好代码的决定性因素不是你懂多少“提示工程技巧”而是你能不能把任务拆到AI可以一次完成的最小粒度。4.1 我的“反AI套路”Prompt方法论没有魔法句式只有结构纪律网上流传很多所谓“神级Prompt句式”什么“你是一位拥有20年经验的资深架构师”“请你一步一步思考”。我实测下来这些东西在写代码场景里作用非常有限。真正有效的是以下这套被反复验证过的结构纪律第一场景前置。先告诉AI它面对的什么环境、集成约束是什么、输出会被谁调用。比如“你现在在为一个Python后端项目生成模块所有函数必须使用类型注解返回类型必须是dataclass调用方是FastAPI路由层。”第二需求定义到“验收标准”级别。不要只说“写一个爬虫脚本”要说“写一个Python函数输入为URL列表输出为列表对应的Markdown文本列表要求忽略所有script/style标签如果请求失败重试2次”。验收标准的颗粒度直接决定AI输出的质量。第三格式锚定。每个函数都必须有明确的输入输出结构即使是AI生成的代码也必须在生成前就约束好边界。否则AI非常容易自行发挥设计一个“看起来合理但和你项目其他部分完全不兼容”的接口。第四小步提交与问题合流。我每轮的需求规模都控制在一个函数、一个组件、一个页面绝不一次提交“请写一个完整Agent系统”。在代码项目里上下文切割越小AI写错的概率越低代码越容易验证。4.2 让AI“自纠错”的循环设计错误反馈比正确示例更重要10天里AI生成的代码不可能全对。但小One项目的生成代码整体返工率大概只有15%左右。这个数字背后靠的不是运气而是一套“AI自纠错”机制。我的做法是写了一个脚本捕获AI生成代码的报错日志然后把报错信息原封不动投喂回给AI并追加一句“仔细阅读以下错误信息结合这段代码上下文重新生成修复后的版本。”AI对这种反馈方式的修复成功率相当高因为它本质上是一个“最小差分修复”任务——上下文中已经有它自己刚生成的代码和明确的报错信息它只需做局部修改。有个细节值得注意不要直接把“整个错误日志”全量抛给AI先人工看一眼只提取和错误相关的最关键2-3行。错误日志有大量无关的路径、依赖版本信息全量投喂的后果是AI可能错误地把某个无关警告当成错误根源然后瞎改一通。我吃过几次亏之后每次都先手动把错误日志“清理”到可读状态再投喂。4.3 对“用AI写代码”这事的重新定位它替代的是什么不替代的是什么10天下来如果非要用一句话总结我对“AI写代码”的定位变化那就是——AI不是替代你写代码是替你把“从想法到能跑起来的代码”这条路的摩擦成本降到了极低。这条路上真正能提供增量的还是人类拆需求、定验收标准、评结果质量。所以那个“代码全AI写的”才会成为标题里最吸引眼球的噱头。但严格讲这不准确。我用自然语言反反复复让AI改这改那本质上跟以前用IDE写代码是一回事只是交互载体变了。区别在于以前我敲的是语法现在我敲的是“意图”。5. 10天踩坑实录AI写代码的隐性成本与“朴素”的解法这章专门讲坑。项目虽小但几乎每类典型问题都碰到了。5.1 上下文爆炸是第一批遇到的典型问题Agent任务执行过程中每一次工具调用结果都会拼入上下文而工具结果动辄几千字。跑到10多步之后上下文长度严重消耗Prompt中间部分直接被截断——截断就截断吧问题在于AI根本没意识到自己被截断了它会一本正经地继续完成输出编造它“认为”存在的结果。这在AI编程里是特别隐蔽的坑因为它不报错。我自己最终采用的方案是上下文“摘要化”。每次执行器返回工具结果后调用一次大模型做强制摘要把结果压成150字以内的结构化要点再存入上下文。这一步牺牲了一点细节但保证了整个长任务过程不至于丢失前置信息。摘要Prompt是“将以下工具执行结果压缩为150字以内的要点保留所有事实性数据与结论。”另外一个很实际的经验是能截断的绝不整段保存。HTML正文提取之后立刻切前2000个字符搜索结果列表只保留前10条。细节越少上下文越干净。5.2 外部工具的不可用会十分钟内瓦解掉AI代码的信心第三天我用爬虫脚本抓取某个大型新闻网站时连续遇到403禁止访问。第一反应是让AI增加请求头伪装第二次又遇到验证码检测页。这种外部环境不可控的问题对AI生成的代码来说极其致命——因为AI生成代码时假设的是“理想网络环境”。针对这种问题最终的解法其实非常朴素增加了一个人工可介入的“跳转确认”提示。crawler脚本如果检测到验证码页面或登录墙会返回状态BLOCKED。主Agent收到后不再尝试硬爬而是记录“该站点无法直接抓取”然后在最终报告里注明信息获取受限。这是一种非常“搜索引擎式”的解法——抓不到就不抓了承认信息缺口总比编造内容强。注意AI Agent工具调用必须把“无法完成”本身当成一种正常返回值而不能让系统把它当成异常崩溃。这个设计原则适用于所有Agent项目。5.3 “看起来对了”的隐性bug反而比崩溃性bug难修崩溃性bug有报错堆栈有直接的失败信号AI修起来很快。真正让人头疼的是“看起来完全正确但结果跑偏”的隐性bug。举一个真实案例小One在执行“检索并抓取指定公司官网”时crawler脚本正确返回了网页正文但正文里包含了网站导航栏和侧边栏的文字“首页 产品 关于我们 联系我们”等重复信息。Agent后续的任务决策被这些无关信息带偏了最终报告里出现了“官网导航栏包含五个一级栏目”这种垃圾结论。原因是我的crawler脚本没有做正文区块提取只是简单把所有可见文字全抓了下来。AI代码“能跑”但跑出来的结果完全不是预期。修复方式也很简单给crawler增加一个extract_main_content()函数采用“文本密度”策略识别正文主干内容过滤导航栏和页脚字段。这类问题AI自己几乎不会主动发现因为它根本不知道你的最终任务要什么。让AI跨模块质检在目前的技术阶段基本是靠不住的。6. 效果评估与外界争议那些被当成“冤大头”的收购真的不值吗开发完小One之后恰逢业内关于某科技巨头重金并购AI团队的讨论热度上升。标题里的“小扎140亿并购像个冤大头”其实映射的是这样一类观点如果AI代码用10天就能做出一个类Manus的Agent那花上百亿收购一个同类团队是不是太亏了从我个人的开发体验出发我的看法是这个类比忽略了“原型”和“产品”之间的鸿沟。6.1 小One和商用Agent的差距具体差在什么地方我列几个关键指标维度小One商用级Agent任务成功率7-8成受工具稳定性影响大需要达到95%以上才有商业可行性长任务稳定性超过30分钟有概率状态异常需要支撑小时级任务不丢状态并发能力仅支持单任务串行必须支持多租户并发调度工具生态3个自研脚本数十个精心维护的集成故障恢复手动重启自动检测故障并重试/降级安全管控无严格的权限隔离、行为审计、合规审查论原型10天确实已经够“惊艳”了但论产品商用Agent需要的是在一个可控边界内持续交付的确定性。所以我一直觉得“10天做出Manus替代品”这个说法本质上是技术验证的胜利而非商业产品的成立。我个人的判断是那个140亿的收购案买的价格不在于这个团队10天能做出什么原型而在于团队在数据积累、工具生态、失败路径、以及生产级Agent基础设施上的know-how。钱买的是确定性——这正是原型项目最缺乏的东西。6.2 对AI编程市场的影响从“能不能”到“值不值”的转折另一个值得展开的话题是这类10天项目对程序员市场意味着什么我认为它让“AI编程能不能干这个”的问题正在快速消失取而代之的是“AI编程在这个场景下值不值”。“值不值”考量的因素很复杂包括任务颗粒度、验收难度、试错成本等。落代码生成这种和业务逻辑耦合紧、需要精细把控的结构AI的容错率还不够落独立模块、边界明确、能做单元测试的代码段AI已经能很好胜任。我也想说句公道话AI编程让编码本身的难度下降了但让“理解问题、拆解问题、定义验收”的难度上升了。这个能力的价值在10天开发中展露无遗——如果我不会拆系统、不会设计工具边界、不懂验收标准这3000行代码再给AI两倍时间也生成不出来。7. 最后再说几个实在的建议项目走到第10天收尾的时候几个同事问我同一个问题“如果让我重新来一遍你会从第几天开始做什么不一样的事”这个复盘价值很大。第一我会从第1天就把数据库状态表设计好而不是第7天才补状态持久化。AI生成代码的能力再强中途改数据模型都是一场灾难——所有已生成的代码都依赖旧字段搜索替换改起来不彻底重做整个模块又浪费两三天。数据模型先行是AI编程项目里最该提前做的事。第二我会在第2天就固定好“工具结果协议”的版本。项目第3天第一次接入searcher和crawler时就出现了输出结构不一致的问题。如果一开始有协议规范能少走至少半天弯路。第三我会更早引入“人工评审关口”。整个10天里最危险的时刻不是某一天功能写不出来而是第5天晚上我盯着AI生成的800行代码发现自己其实没有完全理解其中200行的逻辑但测试又能通过。这种情况特别容易滋生“感觉差不多就行”的凑合心态。AI编程项目里人工理解度跟不上代码生成速度是常态但要确保关键路径上的每个核心模块自己都能看懂它的大体逻辑。盲目信任是最大的坑。第四个关于个人的体会完成这个项目后我把自己日常开发流程固定成了三个步骤需求拆解目标、接口契约先行、AI小步生成自纠错。这套流程能做到平均半天产出一个可用模块的速度换做之前我自己写至少要两三天。这不是骇人的效率提升而是对已有能力的一次松绑。AI不替你做决定它替你省下执行损耗把你从键盘语法细节中解放出来让你回归到更重要的“做什么、怎么做才合理”的问题上。小One这个项目已经跑完但它的终点其实也是所有AI工程类项目的起点一个能跑的Demo离一个好产品还差着十倍的修复、踩坑、打磨、重构。那些看起来像“冤大头”的巨额收购买的内容大概率不是AI本身写的那几千行代码而是代码背后一个人或一群人对它Next Phase判断的价值兑现。写这篇文章没有教谁做产品的初衷只是记录一个10天内被AI写代码效率震撼、同时又被它的边界狠狠教训过的人对这次实验最诚实的一段总结。如果你也在走这条路祝你能比我更早摸到那些坑的位置。