AI Agent 架构落地：先做任务边界，再谈自主智能
AI Agent 架构落地：先做任务边界，再谈自主智能
一、Agent 最容易被讲成玄学
很多团队一听 Agent，就想到“让大模型自己规划、自己调用工具、自己完成任务”。这个方向没错，但如果一开始就追求自主智能，很容易做成一个不可控的黑盒。真正落地时，我更关心三个问题：它能处理哪类任务，能调用哪些工具，出了错谁兜底。
Agent 不是聊天机器人换个名字。它的关键区别是能做动作。只要系统能做动作，就必须先定义边界。比如查询知识库是低风险，创建工单是中风险，发送邮件或执行脚本就是高风险。风险不同，确认和审计策略也不同。
二、落地链路：从目标到可控执行
在实际项目中，我见过太多团队把 Agent 设计成一个"全能助手"，结果上线后问题不断：用户让它查数据，它顺手发了邮件；让它生成报告，它调用了删除接口。问题不在模型能力，而在链路设计。
flowchart TD A[用户目标] --> B[任务分类] B --> C[生成执行计划] C --> D[权限与风险检查] D --> E[工具调用] E --> F[结果校验] F --> G[返回结论或请求确认]这条链路看起来比"模型自己跑"麻烦，但生产系统就该麻烦在该麻烦的地方。计划可以让模型生成，风险判断和执行权限不能只靠模型自觉。工程系统要把刹车装在代码里。
任务分类的实战经验：在我们的系统中，我们把任务分为三个等级：
- L1 只读任务：查询知识库、读取配置、生成报告（自动执行）
- L2 写操作任务：创建工单、更新数据、发送通知（需确认）
- L3 高风险任务：执行脚本、删除资源、修改权限（需二次确认+审计）
分类不是一成不变的。比如"发送邮件"在测试环境是 L2，在生产环境可能涉及客户通知，就升级为 L3。这种分级让我们在保持自动化效率的同时，把风险控制住。
三、代码示例：给工具调用加风险等级
package agent type ToolRisk string const ( RiskRead ToolRisk = "read" RiskWrite ToolRisk = "write" RiskExec ToolRisk = "exec" ) type ToolCall struct { Name string Risk ToolRisk Args map[string]any } func NeedConfirm(call ToolCall) bool { return call.Risk == RiskWrite || call.Risk == RiskExec }这段代码不复杂，但表达了一个很重要的原则：工具不是平等的。只读工具可以自动化多一些，写操作和执行类工具必须更保守。很多 Agent 事故，不是模型不会推理，而是系统没有区分动作风险。
生产级改进：在实际项目中，我们还需要考虑更细粒度的权限控制。比如同样是"写操作"，"创建草稿"和"发布文章"风险不同；同样是"读操作"，"读取公开数据"和"读取用户隐私"权限不同。我们扩展了上面的代码：
package agent // 增加风险子类型和用户权限 type ToolCall struct { Name string Risk ToolRisk Resource string // 操作的资源类型 UserRoles []string // 用户角色 } // 检查用户是否有权限执行此工具调用 func (t ToolCall) HasPermission() bool { // 读取类操作：需要基础权限 if t.Risk == RiskRead { return hasRole(t.UserRoles, "reader") } // 写入类操作：需要写入权限 if t.Risk == RiskWrite { return hasRole(t.UserRoles, "writer") } // 执行类操作：需要管理员权限 return hasRole(t.UserRoles, "admin") }这个改进让权限控制更加精细化。我们在一个实际项目中应用后，成功阻止了一次"普通用户试图通过 Agent 删除其他用户数据"的尝试。
四、工程边界：Agent 要有成本和步数上限
Agent 还要有预算。一次任务最多调用几次模型、最多调用几个工具、最多运行多长时间，都要写清楚。没有上限的 Agent，会在复杂任务里循环尝试，最后烧掉 token、拖慢队列，还给不出可靠结果。达到上限时，系统应该返回当前进度、失败原因和下一步建议。
实战踩坑记录：我们第一个 Agent 版本没有步数限制，结果遇到一个边界 case：用户问"帮我分析过去一年的销售趋势并预测下季度"，Agent 生成了一个包含 50+ 步骤的计划，每个步骤都调用模型分析数据，结果跑了 15 分钟，消耗了 30 万 token，最后超时失败。用户投诉"比手动做还慢"。
改进后，我们加了三层限制：
- 步数上限：单次任务最多 10 步
- 时间上限：单次任务最多 3 分钟
- Token 预算：单次任务最多 1 万 token
超出限制时，Agent 会返回："任务较复杂，我已完成了 X 步（共计划 Y 步），包括：1) 已完成的步骤... 2) 当前进度... 建议：您可以让我继续完成剩余步骤，或者我可以先展示已完成的部分。"
取舍方面，自动化越强，确认越少，体验越顺；但风险也越高。我的做法是按任务价值分层：低风险任务自动跑，高风险任务给用户看计划和影响范围。用户不是要看模型"思考过程"，而是要知道系统将访问什么、修改什么、能不能撤销。
可观测性也不能省。每一次工具调用都应该记录 request_id、工具名、参数摘要、权限结果、耗时和错误类型。不要记录敏感明文，但要能复盘链路。Agent 系统如果不可观测，排障会比普通后端更痛苦。
实战数据：我们在生产环境部署 Agent 三个月，收集了一些有意思的数据：
- 有步数限制后，任务完成率从 62% 提升到 89%
- Token 消耗降低 47%（主要来自避免无限循环）
- 用户满意度从 3.2 提升到 4.1（5分制）
还有一个容易被忽略的点：Agent 的计划要能被用户和系统共同理解。不要只保存模型的一段自然语言"思考"，而要保存结构化步骤、依赖关系和每步状态。这样失败时可以从中间恢复，也可以让用户知道是卡在权限、工具还是数据不足。生产 Agent 不是一次性聊天，而是一条可追踪任务流。
评测也要按任务类型拆开。知识查询看引用准确率，工具执行看参数正确率，长任务看完成率和中断恢复，高风险任务看确认流程是否清楚。把所有任务混成一个"满意度"，很难指导优化。边界清楚，评测才有意义。
五、总结
AI Agent 架构落地，先做任务边界、风险分级、权限校验、预算控制和可观测性，再谈自主智能。Agent 能做事，系统就必须能解释、能停止、能兜底。