一、近期的总结
最近一个月，主要忙于三件事：
1、参加软考高项，准备了半年，终于告一段落。不得不说，通过软考高项的学习，第一次全面系统学习了当前的计算机行业知识，也把我对项目的全流程认知以体系框架进行了重构，感谢这段时间相对空闲的工作，终于对10年工作经历做了系统总结。
2、通过github download了不少有意思的项目，尤其是openmanus，让我回到大学的编程课，第一次完全从程序员角度去思考需求和实现方式。我使用trea也做了一个manus clone的项目，加深对多agents开发的认识。
3、和2支AI团队做了深入沟通。一个是华师大创业团队在B端做垂直领域的员工智能助手，另一个是硅谷回来的团队给网安做内容审查。
很有意思，我原本以为在AI时代，产品经理的角色并不重要，毕竟有想法就可以很低成本验证，试错成本和周期都被压缩到极低。但我错了，脱离场景的技术，只会野蛮生长。这种盲目的状态造成大量资源浪费、和市场脱节。
另一个深刻的认识是团队组织架构的影响。靠合同和派工单驱动的外包型开发公司，对责任和风险的规避极大下降，但也会导致丧失产品敏感性，很难带来市场的开拓。当然，本来风险和收益一直是强相关的。
二、ReAct Agent概述
上半年的Agent，本质都是ReAct架构，具体的过程是：
1、先有个叫planning的agent，对用户输入的内容进行think，评估任务的复杂程度，拆分为tasks或checklist，并识别每个任务所需要的能力和先后顺序。一些关键信息会通过记忆变量进行存储。openmanus会通过system prompt和next step prompt组合对每个agent工作进行更清晰定义；
2、然后每个task会指派给action agent去执行，action从factory中调用工具（比较多的就是网页搜索、图片识别、图片生成、shell、生成代码、文本内容转换为pdf等）。工具执行完成后，返回observation，反馈是否执行成功。action将执行结果返回给planning，planning更新checklist的任务状态。当action返回结果偏差较大或执行效率太低，planning会更新checklist；
3、当planning调用最终的审查或测试agent判断结果达到用户满意，将最终结果输出。
三、通过code介绍manus的工作原理
接下来以openmanus的代码为例，详细说明如何实现的。其实对于我们来说，重点关注app这个文件夹就可以了。openmanus提供了requirements文件，所有的依赖自动完成，安装后在config中配置自己的api就可以了。
1、最外侧的核心是main、run_flow这两个不同的启动方式。main是单agent，直接响应指令并调取工具完成；flow则用到了前文所述的多agent完成任务。
2、app路径下分为agent、flow、mcp、prompt、sandbox、tool。其中mcp是用于配置mcp协议，sandbox是通过沙箱环境来保障代码执行，应用层分为agent、flow、prompt、tool四个核心模块。
- agent目录下的继承关系为：
BaseAgent→ReActAgent→ToolCallAgent→ 具体Agent。通过base agent去记录运行状态、存储变量、设置最大执行步数（这块感兴趣可以看下智谱最新推出的coco，能更直观了解）；ReAct agent实现think、act和step方法执行具体任务；toolcall agent管理工具，并可进行拓展，获得更多工具调用能力。 - flow是通过run_flow去调用的，用于多agent协作，包括base、planning和flow_factory。base定义基础的流程，planning实现多步骤任务规划，包括checklist、调用具体agent执行任务，进行状态管理。
- 对于tool的调用，之前用coze或dify，是通过工作流完成可视化操作和参数的配置，看openmanus是通过LLM生成的结构化参数进行调用，本质上是一样的。
在openmanus框架中，swe是个非常值得注意的组件，全称是“Step-Wise Executor（逐步执行器）”，那它和planning有什么区别呢？
功能定位上，Planning属于任务分解层，负责将抽象目标转化为可执行步骤。例如用户请求"分析最近黄金价格走势"，Planning Agent会生成"抓取数据→清洗→建模→可视化"的任务链。而SWE属于执行引擎层，它接收Planning输出的任务清单，按顺序调用具体工具执行每个步骤。
planning是通过LLM的prompt进行拆解checklist，下发具体指令，依赖大模型的推理能力和prompt，是具有思想的管理者；而swe是执行程序，按顺序调度并监控每个任务的执行情况，是机械的执行者。
那openmanus是如何保障这么长的工作流，输出结果的一致性呢？答案是base agent下的memory类。这个组件负责管理agent在执行任务过程中的状态、上下文和历史记录、每个agent的当前执行状态（如是否空闲、完成、报错等）、多轮对话、任务执行历史、工具调用的输出参数和输出结果、任务进度。
是不是感觉prompt和CPU、memory和内存有点类似？
只看描述，似乎base agent和memory一样，但是base是做具体的执行，memory是将过程中的状态、结果全部记录下来。
四、自己试着开发一个manus
之前尝试参考manus的框架， 自己开发一个。通过chatgpt生成项目目录结构，然后通过venv创建虚拟环境，wrapper配置好llm，web_search中也参考manus使用playwright爬网页。但试了一天，还是无法run起来，就先放弃了。
虽然现在都在说AI能实现一个人的公司，打造所谓的超级个体，但还是很依赖这个人本身的积累，还有很长的路要走。
manus_clone/├── venv/ # Python 虚拟环境├── .env # 环境变量（API Key 等）├── requirements.txt # 依赖列表├── main.py # 项目入口示例├── agent/ │ ├── __init__.py│ ├── agent_core.py # 核心 Agent 调度逻辑│ ├── llm_wrapper.py # LLM 接口封装（OpenAI / 本地模型）│ ├── tools/ # 各类工具模块（搜索、邮件、文件读取等）│ │ ├── __init__.py│ │ ├── web_search.py│ │ ├── file_tool.py│ │ └── email_tool.py│ └── utils.py # 通用工具函数（日志、时间戳等）└── README.md # 项目说明