2025 年 Agent 技术持续演进，已从简单任务处理向具备独立规划、协作能力的智能系统转变。文章从系统设计视角出发，先梳理 Agent 的核心定义与架构框架，再深入分析决定其能力上下限的关键因素 ，最后还分享了构建类 Manus Agent 系统所需的前后端技术栈，为 Agent 产品开发与研究提供参考。
2025 Agent元年已过半，Agent的出现仿佛重新定义了AI这项技术，现在逢人提及AI，基本上大多都指向Agentic Intelligence，而不再是 Artificial Intelligence了；AI技术一路进化，从最初的仅能做一些简单的分类任务，到能够上知天文下知地理与人类对答如流，再到能够精准地理解人类意图到完成具体任务规划、拆解、执行且清晰地指导人类、与人类协作共同完成任务，这中间少不了底层基座大模型的进化，当然也少不了一些工程化技术框架（如Langchain等）的支撑。
近来本人在负责、思考和实践Agent产品相关内容，对Agent的理解和实践体会又进一步加深了，因此本文想从系统设计的角度，简单探讨下如果要开发一款类似于Manus或扣子空间的Agent产品，在产品和技术层面，需要做哪些工作？以及决定一款Agent产品能力的上下限的核心因素是什么？供对AI、Agent产品技术感兴趣的朋友，一同探讨。
注：Agent商业化相关内容，暂不在本文探讨范畴内。
图△ Agent系统架构参考
要聊Agent，Agent定义不得不谈，所以这里再放一些Agent概念相关的东西，供各位了解和回顾~
（△图源：OpenAI官方）OpenAI认为，Agent是“能够代替你独立完成任务的系统”。
（△图源：吴恩达教授）
吴恩达教授，则给出了Agentic Reasoning的四个构件，分别是反馈（Reflection）、工具调用（Tool Use）、规划（Planning）和多智能体协作（Multi-agent Collaboration）。
业界还非常常用的、用来讲Agent组成和架构的图如下：
（△图源：https://lilianweng.github.io/posts/2023-06-23-agent/）
包含四个部分：工具、规划、记忆与执行。
关于Agent的定义和大的架构设计，都是大差不差的。本人认为，我们完全可以把Agent的终极形态想象成人（Agent=人的替身、代理），人有哪些能力，理想态的Agent就有哪些能力（只不过有些能实现、有些可能无法实现和落地罢了）。
人有脑子、有手、有工具使用的能力；人能够思考和决策、做出行动、复盘反思、人是有记忆的；人是社会性动物，人是有组织的有协作能力，同时也是一个独立的个体；人大多会讲话，会微笑，会生气，有七情六欲（虽然AI无法像人一样有真正的脉搏与心跳，但可以在某种程度上，让AI或实体机器人具备这些能力从而更像人类，或是给机器人装一个电子心脏（若有必要的话）也未尝不可；人的心脏还不是生物学家或者医学家定义的）..
.好，下面探讨一下什么样的Agent工具算好？什么样的Agent工具算差？即决定一款Agent工具性能的上下限因素分别是什么。
这个问题，我实际想探讨的是像Manus、扣子空间这些通用Agent工具，甚至是Cursor、Trae、Windsurf这些AI编程工具，其能力上下限由什么决定。了解这些Agent工具的能力上下限，有如下两个重要价值：
1）作为用户，我们可以知道什么样的任务，可以借助什么样的工具能够完成、完成到什么程度，即可以帮助我们在完成特定任务，如行业调研写报告、甚至是开发App时（打工or 创业），进行合适的工具选型，从而将idea落地或者让AI为自己打工，自己去做别的更重要的事情。
2）作为创业者或投资人，可以衡量一款Agent应用或平台的商业价值、当前水平与未来潜力。好，下面我们来具体看一看决定一款Agent产品能力的上下限因素，到底是什么。
——我们可以站在用户视角提出prompt出发，来看一看Agent处理用户需求任务的完整链路，进而找到决定Agent好与坏的核心因素(p.s.分析和优化任何一个产品/模块的指标，其实都可以回归到具体的流程链路上，如RAG的效果如何优化？某产品的用户付费转化率下降了，如何优化？都可延用这个分析框架）。
图△ Agent响应用户prompt 核心流程
Agent响应和处理用户prompt的简易版业务流程如上图所示，其中各个模块的角色与作用，可以类比如下：
1.总指挥（LLM）——战略大脑不干具体活，但决定：“用户说‘分析竞品’，这是个复杂任务，得拆。”“先搜信息，再对比，再出报告。”“代码跑错了？可能是数据格式问题，试试转成 CSV。”它输出的是“意图”和“方向”，不是具体指令。
✅ 能力依赖：大模型的推理、规划、自我修正能力。
2.架构与流程设计师（调度引擎）——战术中枢接收“总指挥”的战略意图，转化为可执行的流程图，并负责：任务编排：串行？并行？条件分支？状态追踪：哪个步骤成功/失败？中间结果存哪？错误处理：失败后重试、降级、报警？资源调度：高优先级任务先执行？
✅ 典型框架：LangChain Agents、AutoGPT 的 Planner 模块、MetaGPT 的 Role-Based Workflow。
3.大头兵（工具执行层）——原子执行单元
每个“兵”只会一件事，且无上下文理解能力：search_tool只会 Google 一下，返回网页片段code_interpreter只会运行你给的代码，不关心目的email_tool只会发邮件，不管内容是否合理它们是原子粒度的、无状态的、可复用的。
✅ 关键设计原则：高内聚、低耦合、易替换
这像不像一家组织的组织架构？所以你会发现，有些Agent框架就是按照产品研发的流程来设计各个模块和各个模块的职责及整体架构的，比如crewAI;至于sandbox，也异常重要，这是将一些代码和程序编写的任务执行结果交付给用户的必要模块，因为有些用户并不会进行复杂的代码部署。所以通用Agent要具备普适性的话，势必要支持在线运行代码、供用户在线调试和验收效果（即做到交付物的可观测），这时就需要sandbox。
总结：以上四部分，构成了一个Agent系统的核心，Agent系统能力上下限也主要由这四部分能力的上下限决定。
1.大模型的语义理解、任务拆解与规划能力，决定了Agent的“智能上限”；
智能能力下限取决于：模型是否具备基本的指令遵循能力（能否听懂用户意图）是否支持Function Calling / Tool Use（能否识别何时调用工具）是否能做多级推理（如：先查数据 → 再清洗 → 再分析 → 再画图）
2.“手脚”：可用工具的丰富度与易用性（决定“行动上限”）
能力下限取决于：是否有基础工具链（搜索、代码执行、读写文件）工具接口是否稳定、参数是否清晰（如：search(query: str)vs 一堆模糊API）
能力上限取决于：工具的覆盖广度（能否调用企业内部系统、CRM、ERP、数据库？）工具的组合能力（能否把“爬网页 → 提取表格 → 写入Notion → 发邮件通知”串成工作流）工具的自动化程度（是否需要人工授权？是否支持OAuth？）
🔧 举例：只有代码解释器 → 只能做数据分析加上浏览器自动化（Playwright）→ 可以操作网页
3.“神经系统”：调度框架与执行流程设计（决定“内在秩序上限”）
即使大脑聪明、手脚灵活，如果没有好的“神经协调系统”，也会混乱。
4.“身体环境”：执行沙箱的安全性与性能（决定“落地稳定性和可观测性”）代码沙箱的安全性是否隔离网络？是否限制CPU/内存？是否防无限循环？执行效率代码运行延迟是否影响用户体验？（>3秒就容易让用户焦虑）可观测性能否实时输出执行日志？能否可视化任务进度？
⚠️ 风险：一个无限 while True 循环可能拖垮整个服务。
说明：这里仅站在本人认知水平和对Agent行业和实践理解基础上，给出一些结论和参考~
1、可参见一些开源的Agent技术框架，在此基础上二开和改进；
2、参考借鉴一些开源Agent技术框架，选择自研（自主设计框架+全套自研）；
3、起码要包括本人前述的四大模块：大脑、调度引擎、工具、执行单元（含在线沙箱），以及结构化信息表达引擎（服务端负责结构化内容输出、前端可视化表达引擎负责将结果展示支持与用户交互）；
给大家整理了一些常见的Agent技术框架（偏服务端）：
以及用来开发Agent的前端技术栈：
1.前端框架（UI 基座）
2.Markdown 渲染引擎（基础能力）
3.代码块高亮与交互
4.表格与数据可视化
5.富文本与可交互内容
6.样式与布局系统
*7.服务端渲染与性能优化
以上可根据自身业务需求特点，选择合适的技术框架开发。
本文由人人都是产品经理作者【产品蝶道】，微信公众号：【产品蝶道的AIGC知识库】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。