学完 Agent 的基本概念后，最适合做的练习，是亲手完成一条有业务结果、也有明确边界的任务链路。
这篇教程实现一个工单助手：用户询问报销申请为何待补材料，助手查询本人申请、检索可访问的制度，解释原因；用户要求申诉时，助手准备草稿，由用户查看并确认后，应用创建工单。我们会把模型决策、工具执行和业务写入分别实现，再用测试检查它们如何协作。
项目使用 Python 和 SQLite，业务代码只依赖标准库。你可以先用不联网的模拟模型跑通流程，再切换到 Anthropic Messages API。文章按“做什么、写哪个文件、怎样运行、如何验收”展开，全部模块与测试直接写在正文中，可以从空目录逐步完成。
如果还没有建立学习顺序，可以先阅读Agent 开发工程师从入门到高级的学习与实战成长路线，再用本项目落实其中的模型调用、工具执行和任务验证。
一个能够回答问题的聊天窗口，距离一个能够可靠完成任务的 Agent 系统，还有多远？
中间隔着工具调用、数据权限、状态管理、失败恢复、效果评测，以及持续运行时的成本和维护问题。Agent 开发工程师的成长，也可以沿着这条链路展开：先理解模型如何参与程序，再让它使用工具完成有限任务，最终能够为真实业务交付可观测、可控制、可迭代的系统。
这篇文章面向准备进入 AI 应用开发的程序员，也适合已经做过聊天机器人、希望继续进阶的开发者。我们用一个逐步升级的“企业知识库与工单助手”贯穿各阶段，把学习内容对应到可以交付的项目和可以验证的能力。前半部分解释各阶段应掌握的知识，后半部分给出六周基础准备、二十四周逐周任务，以及第 25 至 52 周的高级实践安排。每个周期都列出要做的事情、交付物和验收要求，可以直接作为个人学习计划使用。
优先建立模型调用、工具执行和评测的完整闭环，再根据任务需要引入检索、持久化和多 Agent 协作。 技术栈可以更换，这些能力会持续影响项目质量。
做了几个产品之后，往往会遇到一个问题：代码仓库、演示地址、截图和介绍散落在不同地方，别人很难快速理解你做过什么，也不知道应该先体验哪一个。
一个个人产品集网站，可以把这些内容组织成一条清楚的访问路径：先认识你，再浏览产品，最后进入案例、打开演示或者联系合作。
这篇教程用 Codex + Cargo.site 完成这条路径。Codex 帮我们整理材料、制定设计方案、编写局部样式和检查页面；Cargo 负责可视化编辑、页面组织和发布。我们会围绕同一个案例，逐步给出提示词、示例输出、Cargo 操作和验收方法。
设备每隔几秒上报一次温度，服务端接收并记录；设备断网后，后台还能看到它已经离线。这类需求很适合用 MQTT 串起来。
真正接入项目时，需要处理的不只是 Publish 和 Subscribe：连接成功是否代表订阅已就绪？断线重连后谁来恢复订阅？发布超时还能不能重试？QoS 1 是否意味着数据库里只会出现一条记录？
这篇文章用一个可以复制运行的 Go 示例，把本地 Broker、温度上报、订阅处理、自动重连、设备状态与正常退出串成完整流程，再说明持久化、业务幂等和生产配置应该补在哪一层。
让 AI 帮忙修改 Go 项目时，代码能编译只是第一步。业务逻辑可能被放进 handler，请求的 context 可能在数据库调用前丢失，一个看似简单的 goroutine 也可能缺少退出路径。
这些问题往往与项目约定有关：分层如何协作，错误怎样转换，事务由谁管理，测试能否访问外部服务。如果每次任务都重新解释，既容易遗漏，也难以保持一致。
这些约定如果只留在聊天里，换一个任务就可能需要重新说明。把它们整理成项目里的 AGENTS.md，能让支持这一机制的编码助手获得持续可用的工作指引。
本文以 Go + PostgreSQL 的订单服务为贯穿示例，介绍如何把工程约定写进 AGENTS.md，并给出一份可按仓库调整的完整模板。文中的分层、路径和测试组织均为示例，需要结合项目实际取舍。
