Text CEO 分享构建无代码 Agent 框架的探索历程与核心设计哲学

从“必须在线”到自主运行的 Agent 演进

演讲者作为 Text（一家15人公司）的 CEO，在2024年1月左右意识到 Agent 技术出现了质的飞跃（如 Opus 4.6），因此请了两周假深入研究如何构建实用的 Agent。他通过自家办公室城堡中的自动割草机器人（robot mower）做比喻，指出理想的 Agent 应像该机器一样全天候无人值守运行。然而，早期的 AI 交互体验类似于“必须坐在拖拉机上的自动驾驶”，即使 Agent 能执行任务，用户仍需通过 TUI（文本用户界面）或手机 SSH-like 应用持续监控和干预。这种“边走边指挥”的模式被演讲者视为荒谬且过渡性的，因为用户不得不频繁改变 Agent 的轨迹，缺乏真正的自主性。他决定构建一个能彻底摆脱这种束缚的系统。

摒弃代码框架，转向声明式配置与事件驱动

在开发过程中，演讲者发现尽管现有的 Agent 框架功能强大，但大部分时间都耗费在代码内的 Prompt 编辑上。相比之下，YAML 等声明式配置方式更易于实现无代码的 Agent 构建。这种方式支持版本控制、Diff 审查和 PR 流程，只需将文件放入文件夹即可由运行时自动加载。此外，传统的 Cron Job（定时任务）仅能解决“何时”运行 Agent 的问题，无法处理复杂的时间逻辑。因此，系统引入了事件驱动架构（Event-Driven Architecture）：当特定条件触发时（如语音笔记上传、新邮件到达），Agent 自动响应。这种机制不仅限于定时任务，而是覆盖了系统中所有自动化场景。

语音笔记处理案例：结构化输出与事件链

以早晨散步时的语音笔记为例，系统不再依赖简单的定时抓取，而是通过事件发射与消费机制实现自动化。当用户录制语音笔记并上传时，系统发出“voice_note_received”事件；随后，“Voice Note Processor Agent”接收该事件，利用结构化输出（Structured Outputs）将语音转录并转化为持久的笔记格式；最后，该 Agent 发射“voice_note_processed”事件。这一过程展示了 Agent 如何通过声明式的输入（accepts）和输出（returns）接口进行协作。随后，“Daily Brief Agent”会消费包括定时任务结果和语音笔记处理结果在内的多种事件，生成每日简报。这种设计使得 Agent 能够像乐高积木一样组合，通过事件总线实现解耦和自动化流转。

从Slack简报看事件驱动架构的必要性

演讲者分享了一个真实运行的个人案例：每天生成“每日简报”并通过Slack发送。这一过程并非依赖复杂的代码图结构，而是基于事件驱动架构。当“Slack消息发送”这一事件发生时，订阅该事件的进程会自动触发并执行后续动作。无需维护边（Edges），Agent只需简单订阅事件即可。这种架构允许任何人通过了解系统中存在的事件来参与编辑，无需掌握编程知识。Fan-out（扇出）和Fun-in（扇入）是免费的，只需放置文件，拓扑结构便根据日志自动涌现。这种设计避免了框架推销的“需要代码图”的复杂性，证明了简单的事件订阅足以支撑实际工作流。这种去中心化的设计不仅降低了门槛，还让系统拓扑随日志动态生成，体现了无代码（No-code）架构的灵活性。在实际操作中，这种基于日志和事件的机制比硬编码的流程更易于维护和扩展。

内容寻址系统：重构请求的可复现性

在构建 Agent 系统的过程中，引入内容寻址系统（Content Addressing System）带来了巨大的工程红利。这一机制允许从图结构中重建原始请求，从而实现对交互过程的精确回放（Replay）。这意味着开发者不仅可以原样重发之前的操作序列，还可以在此基础上进行灵活调整：例如更换底层模型、修改请求参数或尝试不同的处理逻辑，而无需重新从头开始构建上下文。

这种架构使得许多原本需要额外开发的功能变得“免费”且易于实现。通过图结构的持久化存储，系统能够记录完整的状态变迁历史，这不仅简化了调试过程（Debugging），也为后续的系统优化提供了数据基础。相比于传统的线性日志记录，这种基于图的重构能力确保了状态的一致性和操作的原子性，是构建可靠 Agent 基础设施的关键一步。

内核与用户态：解耦 Agent 逻辑

与传统框架将代码封装在抽象层内部不同，该方案借鉴了操作系统的内核（Kernel）与用户态（Userland）模型。在这里，Agent 被视为运行在内核之上的进程。内核负责调度、隔离和记录日志，确保 Agent 的定义与执行环境分离。这种设计允许用户完全脱离特定的 Markdown 格式或前端界面，只要遵循内核的交互协议即可。

"The job of the kernel is actually to make bad actions impossible, not just unlikely."

这一架构的核心优势在于强制性的类型安全。系统通过两个关键边界来保障稳定性：首先是 Agent 与外部世界的交互，即类型化的工具调用（Typed Tool Calls），确保不会调用不存在的工具或传递错误参数；其次是 Agent 之间的通信，即类型化的事件（Typed Events）。这种非协商式的严格约束极大地减少了运行时错误，正如演讲者所言，仅靠这两层类型检查就能避免大量潜在问题。

结构化输出的痛点与自建动机

演讲者 Rémi Louf 来自 Infropic，其公司专长在于结构化输出（Structured Outputs）。他构建此系统的初衷并非为了推销自家软件，而是源于对现有工具在结构化输出方面表现的极度不满。在实际业务中，约 20% 的事件因格式错误被系统拒绝或判定为无效。这一高失败率直接影响了业务效率，迫使团队投入大量精力进行错误处理和重试。

"Infropic was terrible at structured outputs and so like 20% of my events were wrong."

这一经历促使他将该项目作为“吃自己的狗粮”（Dogfooding）的实践。通过自建内核，他们不仅解决了结构化输出的稳定性问题，还实现了更细粒度的控制。这种由痛点驱动的开发模式确保了系统设计的务实性：不追求花哨的抽象，而是专注于解决工程落地中的具体障碍，如错误处理、状态管理和类型校验。

部署成果与开源建议

经过一个月的内部部署，该系统已稳定运行并支持20 个 Agent。这些 Agent 不仅由技术人员开发，也涵盖了业务团队（如简报生成、邮件处理等），证明了其易用性和通用性。在模型选择上，演讲者指出开源模型已足够胜任日常任务。他不再依赖第三方 API，甚至在本地笔记本上使用小型开源模型处理非编码类工作。

"I would advise that today like definitely start building before you buy."

基于此，他向企业提出建议：先自建再购买。对于小型公司或技术 CEO 而言，利用现有开源模型和轻量级框架快速验证需求，比直接采购昂贵的企业级解决方案更具优势。这不仅有助于明确自身真实需求，还能避免被供应商锁定。同时，他呼吁框架开发者务必亲自使用自己的产品（Eat your own dog food），以确保设计的合理性和鲁棒性。最后，他鼓励团队沉浸于实际应用场景中，而非盲目追逐新技术概念。

核心数据与配置对比表

尽管本片段未提供具体的基准测试跑分，但以下表格总结了演讲中提到的关键配置、性能指标及对比结论：

结论

该实践证明了摒弃传统代码框架、采用声明式配置与事件驱动架构，能有效解决 Agent 自主性不足及维护成本高的问题。通过引入内容寻址系统实现请求回放，以及借鉴操作系统内核模型建立类型化工具调用与事件边界，系统在稳定性上取得显著成效：将结构化输出错误率从 20% 降至稳定运行，并成功支撑内部部署的 20+ Agent。其核心优势在于解耦了逻辑与执行环境，降低了非技术人员的参与门槛。

然而，该方案主要适用于具备一定工程能力、追求高可控性与低供应商锁定的团队。演讲者基于自身经验建议“先自建后购买”，并指出当前开源模型已足以胜任日常任务。这一结论强调了在 Agent 开发中，务实的工程落地与类型安全约束比追逐复杂框架更为关键。