10分钟角色构建揭示了真实建筑学的哪些真相
像TrueForge这样的十分钟代理构建工具会隐藏Deep Agents或LangGraph迫使你面对的架构决策：技能、MCP工具、状态以及失败路径。
来源: I Built an Agent in 10 Minutes. Then I Understood Why Building One Takes So Long.
通过使用 LangGraph、Deep Agents 和 TrueForge，我们了解了抽象概念、控制机制以及智能体实际的行为方式。
在开发 DEVIN 的过程中，大量精力都投入到了那些人们在直接使用 AI 智能体时根本看不到的环节中。
连接 Deep Agents 的组件。
将 Daytona 配置为沙箱环境。
利用 Ingest 处理流式数据与后台任务。
让所有这些组件协同工作。
进展十分缓慢。
但在这漫长的努力过程中，人们逐渐清晰地认识到构成智能体系统的真正要素是什么。
不仅仅是模型本身。
围绕它的所有要素。
运行时环境。
相关工具。
沙箱环境。
协调层。
智能体之间交流以及任务交接的方式。
后来一场黑客松出现了，TrueForge也随之诞生。
几乎立刻就显而易见，那些原本需要耗费大量精力手工搭建的基础设施，其实可以交由平台来处理。
构建一个可运行的智能体仅需大约十分钟：连接相关的MCP，加入必要的工具，编写描述其行为的SKILL.md文件，然后直接运行即可。
在花了那么多时间从零开始构建基础设施之后，这简直容易得令人难以置信。
说实话，这真的很厉害。
这正是优秀的抽象层应有的体验。
不过，这种便捷背后隐藏的代价当时还不明显。
十分钟就能搞定的智能体
最初的反应完全是惊叹于这一过程的轻松便捷。
TrueForge负责处理相关的基础设施，而将描述智能体实际应执行任务的职责交给了技能定义。
这确实是一种非常出色的抽象方式。
新增的MCP是可见的。
各种工具也是可见的。
SKILL.md文件同样清晰可见。
所有内容都一目了然，易于理解。
因此人们便养成了习惯，总是优先使用它。
只有经过持续使用后，一个在黑客松期间并未显现的细微问题才浮出水面。
人们关心的并非能够检查什么，
而是真正的架构存在于何处。
单凭一个技能并不足以构成架构
根代理会读取技能文件，并以此决定如何运用所赋予的能力，包括何时以及以何种方式启动子代理。
这意味着一个单独的SKILL.md文件就能悄然决定代理大部分行为结构。
想象一下想要构建类似这样的系统：
Root Agent
/ \
/ \
Researcher Coder
/ \
/ \
Searcher Tester
仅仅告诉根代理“这是你的工具，自行创建所需的子代理并处理问题”与设计整个系统并非同一回事。
真正重要的是直接定义架构：
- 存在哪些代理
- 每个代理负责什么任务
- 哪些工具分配给哪个代理
- 每个代理会接收到什么上下文信息
- 何时应该进行任务委派
- 出现故障后的恢复方案是什么
这就是开始显现出来的区别。
使用 Deep Agents 方法时，架构是需要人工刻意构建的。
使用 TrueForge 时，基础设施部分要简单得多，但行为架构最终取决于核心智能体是否按照预期方式理解技能。
这种依赖性使得整个系统的行为更紧密地与底层模型相连。
性能更强的模型可能会完全按照设计意图来解读技能。
性能较弱的模型则可能对相同的指令采取完全不同的处理方式。
同样的技能文件。
同样的工具。
却产生不同的行为结果。
纸面上的架构并未改变。
只有模型对这一架构的理解发生了变化。
正是这一差距使得这种方法难以被完全信任。
参与AEGIS项目进一步加剧了这种担忧
在开发AEGIS的过程中，团队遇到了一个简单却能揭示问题的状况。
该智能体应当负责调查Node.js事件循环阻塞的情况。
它需要检查代码、复现问题、分析运行时行为、诊断根本原因、提出修复方案，并确认修复措施确实有效。
初期，验证阶段基本上只是向模型下达指令，内容大致如下：
执行实验，比较所得指标，判断修复方案是否真正解决了问题。
然而让大型语言模型自行判断其修复方案是否成功，其实并不能算作真正的验证。
因此，该逻辑中的确定性部分被移至代码中，而非提示文本中。
模型负责进行推理。
系统负责执行测量。
验证器负责发起调用。
这段经历形成了一项如今广泛适用于智能体设计的原则：
如果某事物无法被观察，就无法对其进行恰当测试。若无法测试，就无法对其进行评估。而一旦无法评估，也就无法可靠地对其进行改进。
这正是架构至关重要的原因。
并非因为包含更多框和箭头的图表就一定更优。
而是因为你需要清楚地了解究竟是什么导致了你试图改进的行为。
“它能运行”与“我明白它为何能运行”
两种不同的智能体在技术层面上都可能取得成功。
它们都能完成分配的任务。
在现场演示中，它们的表现也可能都很出色。
真正的考验在于出现故障时。
对于某一类智能体，可以追踪其精确的执行路径：
Root Agent
↓
Researcher
↓
Search Tool
↓
Result
↓
Root Agent
↓
Coder
↓
Sandbox
每个决策点都可以被仔细检查与分析：
为什么会出现这一步？
而对于另一类智能体，只有描述预期结果的规则，具体路径则由模型自行决定。
当这种方式有效时，它看起来极为简单。
但一旦失败，调试时的问题就变得难以解答：
故障是源于模型本身、指令内容、任务分配逻辑、提供的上下文，还是模型自行设计的架构？
第二种情况是更难解决的难题。
而这正是TrueForge所传授的
在接触该平台之前，人们通常认为构建智能体的难点完全在于基础设施层。
实际使用后这种观念发生了改变。原来基础设施只是问题的一半而已。
基础设施是可以被抽象出来的。
行为则难以被抽象。
平台可以提供沙箱环境。
它可以提供MCP接口。
它可以提供流式数据传输功能。
它甚至可以提供完整的运行时环境。
然而，如果你要构建的智能体的行为真正具有实际意义，你仍然需要自己回答一些问题：
是哪个组件在做出何种决策？
什么被允许执行什么操作？
授权究竟发生在哪里？
你对这一流程能了解多少？
你实际上能够衡量或评估什么？
当出现问题时，有哪些手段可以解决？
这些都是绝不能轻易交由他人处理的事项。
要弄清楚失败原因需要多长时间？
在十分钟内组装出一个代理程序确实是一项了不起的成就。
但相比速度，一个更有意义的问题愈发重要：
要弄清楚失败原因需要多长时间？
生产环境不会因为首次演示成功而给予奖励。
它们惩罚的是第十次失败。
那些返回意外结果的工具。
那些较为薄弱的底层模型。
在不应交接任务时却进行交接的代理。
在该交接任务时未能完成交接的代理。
宣称“已完成”，但实际上什么都没做到的代理。
正是在这种情况下，架构才显得至关重要。
实际学到了什么
回顾DEVIN项目，真正的收获并非掌握Deep Agents、Daytona或Ingest这些独立工具，
而是理解了代理系统各组件之间是如何相互连接的。
TrueForge进一步展示了如何快速将这些组件抽象出来隐藏起来。
而使用它也揭示了这种便利性的另一面：
基础设施可以从工作流中消失，但相关行为并不会随之消失。
仍然需要有人来管控这些行为。
仍需有人亲自观察其实际运行情况。
仍需有人评估它是否有效运作。
还有人需要决定在系统出故障时该做哪些调整。
这种责任应当由自己掌控，而非外包出去。
智能体架构的发展方向
这一经验也改变了我们更广泛地理解智能体系统发展路径的方式。
该领域已经历多个发展阶段：
模型 → 工具 → MCP → 智能体 → 深度智能体
在每个阶段，所需的配套基础设施都变得越来越容易获取。
从这一视角来看，未来最重要的层面是围绕模型的支撑框架。
重要的不仅仅是模型本身的原始能力，还有为其提供支持的整个系统：
上下文、工具、执行流程、权限、协调机制、内存管理、可观测性、评估以及控制。
随着模型不断改进，仅靠模型的原始质量已无法成为决定性因素。
未来值得探讨的工程问题将越来越倾向于：
围绕该模型构建了怎样的环境？我们能在多大程度上控制它的行为？
这可以说是构建DEVIN以及后来在十分钟内组装智能体的核心经验。
构建智能体的难度越低，理解其周边所有要素的重要性就越高。