Agentic AI 工程师的 15 个系统：能跑起来，才算会

Suraj Sharma 在 X 上列了 15 个项目，标题很直接：作为 Agentic AI Engineer，你应该构建这些。后面他又给了一份 6 个月路线图。两份内容放在一起看，能看出一个倾向：Agent 工程的门槛不在会不会调用模型，在能不能让系统在并发、失败、成本、权限和评估里稳定运行。原推链接：https://x.com/suraj_sharma14/status/2115413286829298029

15 个项目

1. 异步 Agent 编排器：FastAPI 加 asyncio 事件循环，处理 100 个以上并发 Agent 任务，支持非阻塞工具调用和错误恢复。Suraj 的理由是，while True 循环会阻塞主线程，生产流量需要事件驱动并发。

2. 动态上下文预算装配器：请求前中间件，在系统提示、检索文档和工具 schema 之间分配 token。上下文溢出是生产 Agent 的静默杀手，token 要像云预算一样管理。

3. 严格 Pydantic 工具路由器：强制 LLM 输出符合严格 JSON schema，验证失败时带错误轨迹自动重试。Agent 会编造 API 参数，语法约束解码和 Pydantic 校验把随机输出变成确定性动作。

4. 三层内存与淘汰引擎：工作草稿、会话压缩、语义向量检索，加上自动 TTL 淘汰。无限上下文会带来 OOM 和幻觉，内存需要主动管理、打分和裁剪。

5. 自修复 ReAct 循环：Agent 读取自己的 stack trace，解析编译器或 API 错误，重写失败的工具调用，最多重试 3 次。第一次就失败的 Agent 没用，能自己调试的 Agent 才像数字员工。

6. 类型化多智能体群：用 LangGraph 状态机，让 Researcher、Coder、Reviewer 传递严格类型的状态对象，不传原始文本。单 Agent 处理复杂任务会失败，多 Agent 能分而治之，但原始文本交接会造成上下文漂移。

7. 异步 HITL Slack 闸门：工作流先起草高风险动作，序列化状态，等人工通过 Slack webhook 点击“Approve”，最多等 3 天。高风险自动化需要人类问责，Agent 要知道怎么暂停、等待和恢复。

8. 轨迹评估 CI 闸门：GitHub Action 回放 100 条 Agent 轨迹，如果工具调用序列偏离黄金 DAG，就阻止 PR。只看最终文本会掩盖 Agent 编造 API 调用或跳过安全检查的过程。

9. OpenTelemetry Agent 追踪器：自定义 tracing span，捕获每次 LLM hop、token 数、工具延迟和状态变更，接入 LangSmith 或 Arize。14 步的 Agent 工作流如果无法回放，就很难调试。

10. Agent 间消毒代理：中间件拦截 Agent 之间的消息，剥离恶意指令，防止跨 Agent prompt injection。多 Agent 系统会制造内部攻击面，Agent A 可能被诱导劫持 Agent B 的工具。

11. 沙箱代码执行器：代码解释器在 E2B 或 gVisor microVM 里执行 Python，零外网出口。让 LLM 在主机上跑 os.system() 是灾难级安全风险。

12. 成本 kill-switch 中间件：路由器追踪循环深度和预计花费，超过 0.50 美元立即停止，回退到更便宜的模型。失控的 Agent 循环是一次带账单的故障，可能在你发现前烧掉 500 美元 API 额度。

13. API 到浏览器回退 Agent：主 REST API 返回 404 或超时，Agent 无缝启动无头浏览器完成 GUI 工作流。现实环境很乱，80% 的企业软件没有 API，Agent 要适应破损环境。

14. 影子轨迹比较器：把 5% 流量静默镜像到后台，运行新的 Agent 拓扑，对比工具调用路径和成本，不影响用户。非确定性的 Agent 系统不能直接在生产里安全 A/B 测试，需要影子模式。

15. 公开架构拆解：发布 3 篇深度文章，讲清 swarm 拓扑、状态机设计、Agent 间安全和每任务成本。顶级 AI 实验室招 Agent 工程师，看的是系统设计判断，不是会不会 import LangChain。

Jonathon Byrdziak 在回复里贴了这张图。门系统 v2.7，接近传感器阵列、麦克风阵列、液压阻尼器、冗余铰链。项目清单越长，这张图越像自嘲。

评论区补上的几块

Jatin Garg 问，超时写操作的恢复是不是工具调用的毕业测试。他的理由很具体：安全重试需要知道动作是否已经发生，光捕获错误不够。Suraj 回，如果 Agent 分不清写操作是否已发生，重试就是拿生产数据赌博。

Karan 提了路线图常跳过的权限：Agent 能碰什么，能碰多久，怎么收回。Suraj 同意，最小权限应该是核心阶段，Agent 默认需要作用域访问和可撤销权限。

John Rood 说，Stage 4 卡住人的地方不在检索。向量召回是简单的一半，真正麻烦的是写入规则：什么被保留，带什么日期，两份记录冲突时哪份赢。没有优先级的检索，会把旧决定翻出来，像当前结论一样使用。

Unique Adhikari 建议把评估提前到 Stage 3 之后。工具调用循环一旦有了，几条可回放轨迹加通过失败检查，就能判断后面的内存、多 Agent 改动是真有用，还是看起来更聪明。Suraj 的回应更直接，评估应该成为每个项目的基础，测不出任务成功和回归，就不敢发 Agent 更新。

Yashi Srivastava 问高并发下先记什么日志。Suraj 说，先给完整 Agent run 加 correlation ID，再记录每个工具的输入、输出、状态和时长，早期加每步预算，别让失控重试藏进聚合指标。

Alex Puzanov 认为 Python asyncio 在复杂 Agent 里会崩，建议转 Rust 或 Go。Suraj 回，先用 tracing 和压测证明限制在哪，重写语言不会修复错误的编排逻辑。

Alex Wu 算了一笔路由账：20 个路由变量等于 1,048,576 条轨迹，10,000 条评估覆盖不到 0.01%。未测试余量里的循环，只会在烧完成本后出现在 tracing 里。Suraj 的建议是，关键路由规则穷举检查，边缘情况用 property-based testing，安全不变量要在所有轨迹上成立。

6 个月路线图

Suraj 的另一条推文给了 12 个阶段：Python 与异步基础、LLM 基础、工具调用与结构化输出、内存与状态管理、单 Agent 工作流、多 Agent 编排、HITL 系统、评估与质量保证、可观测性与追踪、安全与护栏、生产部署、开源与作品集。

他在推文里写，Most people watch tutorials. Builders ship systems. 这句话放在这 15 个项目前面，比任何教程清单都清楚。