8.0
热点
AI SCORE
编程提效2026-09-04 03:00
本地构建LLM入职引导Agent：ReAct工作流实战
dev.to · AI#AI Agent#Python#ReAct
Editor brief · 编辑速览
使用Python、Groq API和GitHub构建了可完成入职流程的AI Agent，演示了本地编排与远程推理分离的架构模式，以及ReAct风格工具调用实现。
最近我在本地用 Python、GitHub 和 Groq API 构建并测试了一个基于 LLM 的员工入职代理（agent）。
目标是理解 AI agent 如何将 LLM 与工具、结构化数据、工作流规则和人工审批相结合，以完成一个实际的业务流程。
入职 agent 遵循工具调用工作流：
项目使用了模拟 HR 和合规数据，因此访问配置和通知都是在本地模拟的。
Agent 编排在本地运行，而 LLM 推理通过 Groq API 处理。
Local Python Agent
↓ Employee Profile Tool
↓ Compliance Check Tool
↓ Notification Tool
↓ Access Provisioning Tool
↓ Groq API
↓ LLM Response
↓ Agent continues the workflow
这帮助我理解了一个重要的区别：agent 编排和工具可以在本地运行，而实际的 LLM 推理可以通过远程 API 提供。
工作流遵循 ReAct 风格模式：模型确定下一步操作、选择工具、接收观察结果，然后继续工作流。
对于合规待审的员工：
Get employee profile
↓ Check compliance
↓ Compliance = PENDING
↓ Send reminder
↓ Ask for human approval
↓ Approval received
↓ Provision access
↓ Send welcome notification
↓ Complete
对于合规已通过的员工：
Get employee profile
↓ Check compliance
↓ Compliance = CLEARED
↓ Provision access
↓ Send welcome notification
↓ Complete
这种差异有助于验证合规状态确实控制了 agent 的行为。
在项目过程中，我完成了完整的开发工作流：
在第一次实际的 agent 运行中，我遇到了 Groq API 错误：
模型 "llama-3.3-70b-versatile" 已不再可用，导致 404 model_not_found 错误。
我通过 API 验证了可用模型，并更新 agent 使用：
GROQ_MODEL = "llama-3.3-70b-versatile"
我还把模型选择收拢到一个 GROQ_MODEL 常量后面，而不是将模型标识符硬编码。
这是一个有用的提醒：LLM 集成和其他 API 集成一样，也有依赖管理问题。模型标识符和提供商可用性可能会发生变化，从而破坏一个本来正常的应用程序。
第一个任务是添加一名新员工：
EMP-2026-0849
Arjun Reddy
Software Engineer L4
Platform Engineering
该员工以 CLEARED 合规记录添加到模拟 HR 数据库。
然后我运行了干跑验证，并针对新员工执行了 agent。
Agent 成功检测到 CLEARED 合规状态，直接进入访问配置阶段，而没有触发人工审批门控。
我还测试了现有的合规待审员工，以确认人在环（human-in-the-loop）行为仍然完好。
最大的收获是：AI agent 不只是一个 LLM prompt。
一个有用的 agent 结合了：
LLM 可以决定下一步应该发生什么，但周围的应用定义了存在哪些工具、哪些数据可用、哪些操作允许，以及何时需要人工审批。
当从 AI 演示转向生产系统时，这种分离变得尤为重要。
这个项目让我亲身体验了一个小型 AI agent 的完整生命周期：搭建开发环境、集成 LLM API、调试模型兼容性问题、实现新的工作流场景、测试不同的执行路径，以及通过 GitHub 提交工作。
更重要的是，它帮助我理解了 LLM、工具、工作流状态和确定性业务规则如何协同工作，以自动化真实世界的流程，同时让人类保持在敏感决策的控制之中。