Agent 实践
Agent 不是简单的聊天机器人，也不是传统工作流的换皮。它的基本结构可以理解为：LLM + 规划 + 记忆 + 工具 + 环境。
- LLM：理解意图和生成决策。
- 规划：拆解任务和安排步骤。
- 记忆：保留长期上下文和经验。
- 工具：连接真实系统。
- 环境：提供可执行、可验证、可回滚的工作空间。
为什么需要 Agent
硬编码、低代码和传统工作流适合输入清晰、流程稳定、规则明确的任务。一旦任务依赖非结构化信息、隐性经验、动态上下文、多轮判断和跨工具协作，固定流程就会迅速膨胀。
Agent 的价值，是把自然语言变成任务入口，让复杂流程不再完全依赖人提前写死每一个分支。
Agent 并不完美。当前主要挑战包括响应慢、幻觉、纯文本交互不够直观、长周期任务容易偏移，以及执行结果需要人类校验。因此，Agent 更适合先从“协同完成复杂任务”开始，而不是过早完全接管关键决策。
演进阶段
- 被动式 Agent：以 ReAct 为代表，模型根据用户问题进行推理，并在需要时调用工具。
- 工作流 Agent：以 LangGraph、Dify 等为代表，用工程化约束弥补模型不确定性。
- 自主 Agent：以 Manus、Claude Code、Codex 等为代表，具备更强的规划、长周期任务执行和自我校验能力。
- 自进化 Agent：通过沉淀 Skill、知识、工作方法和项目记忆，让 Agent 越用越贴合具体场景。
Agent 模式选择
Function Calling 是动作，ReAct 是动态探索，Plan-and-Execute 是先规划后执行，Workflow 是流程工程化。
| 模式 | 谁决定下一步 | 特点 | 适合场景 |
|---|---|---|---|
| Function Calling | 模型决定调用哪个工具 | 单步或少量工具调用 | 查订单、查天气、计算、创建工单 |
| ReAct | 模型根据观察结果动态决定 | 多轮探索，路径不确定 | 告警研判、漏洞分析、问题排查 |
| Plan-and-Execute | 模型先生成计划，再执行 | 先规划，再行动 | 多步骤任务、调研、复杂分析 |
| Workflow | 程序或流程引擎决定 | 流程固定，可控性强 | 生产系统、审批流、安全评审、漏洞运营 |
控制权差异决定了工程边界。Function Calling 让模型决定“调用哪个工具”；ReAct 让模型决定“下一步做什么”；Plan-and-Execute 让模型先决定“一整套计划”，再逐步执行；Workflow 则由系统预先决定“流程怎么走”，模型只在某些节点里辅助。
以告警研判为例，Function Calling 可以查询一个 IP 的威胁情报；ReAct 会根据 IP 情报继续查访问日志、业务指标和历史事件；Plan-and-Execute 会先规划查资产、查日志、查情报、查指标、生成结论，再逐步执行；Workflow 会固定为告警输入、资产归属、威胁情报、日志聚合、影响面判断、风险定级、人工确认和报告输出。
实践主题
- 需要设计跨层循环、停止条件与预算：阅读 Loop 工程，区分执行、任务、产品与系统循环的对象和出口。
- ReAct 模式：用最小代码理解模型如何在多轮观察中动态决定下一步工具调用。
- Plan-and-Execute 模式：先把任务拆成计划，再按计划逐步执行并在需要时重规划。
抽象层迁移
Agent 的技术栈正在发生变化：
- Prompt：从深度耦合走向渐进式加载。
- Planning：从简单思维链走向复杂长程任务拆解。
- Memory：从 RAG 走向文件系统化的知识沉淀。
- Tool：从 Function Call 和 MCP 走向 CLI、脚本和 Meta-Tooling。
- Workflow：从刚性流程走向动态组合。
- Environment：从无状态对话走向 workspace、sandbox 和权限边界。
Agent-native workspace
Agent 真正进入日常工作后，界面形态也要变化。把 Agent 塞进一个聊天框，再给它接上工具，只能解决“人问一句、AI 回一句”的局部问题。真实协作更像一个工作空间：人、Agent、文件、任务、权限、审批和历史记录同时存在，系统要让每个参与者知道自己负责什么、下一步等谁、哪些动作已经发生、哪些动作还停在草稿状态。
Agent-native workspace 的核心，是让 Agent 成为可管理的协作者，而不只是在界面上显得更智能。一个可管理的 Agent 至少要有稳定身份、明确职责、可见状态、权限边界和交接格式。否则，团队面对的只是一个匿名自动补全器：它能生成文本，也能调用工具，但人很难判断这段输出属于哪个上下文、能不能继续执行、出了问题该从哪里追溯。
稳定身份很重要。一个项目里可能同时存在写代码的 Agent、查资料的 Agent、做安全审查的 Agent、整理会议纪要的 Agent。它们不应该在同一个匿名对话流里混成一团。具名 Agent 能让人建立心理模型：这个 Agent 擅长什么、权限到哪里、以前做过哪些任务、当前卡在哪一步。身份稳定之后，路由也更稳定，任务可以被分配给合适的 Agent，而不是每次都从一段长提示词重新定义角色。
共享空间也要控制噪音。人和 Agent 都把过程、草稿、日志、工具输出和最终结论丢进同一个频道，短期看很热闹，长期会让上下文不可读。更好的结构是把“工作流内部状态”和“需要人看的交付物”分开：Agent 可以在自己的工作区里探索、检索、试错和整理；当它产出可读结果时，再提交为一个清晰的 draft packet，里面包含结论、依据、变更点、不确定项和需要人判断的问题。
收件箱模型比连续打断更适合人机协作。Agent 不应该每完成一个微小步骤就打断人，也不应该把所有中间状态都推到主工作流里。它可以接收任务，独立处理一段时间，然后把结果放进人的 inbox：这份内容需要审核、这份内容只是信息、这份内容等待发布、这份内容需要补充授权。这样人处理的是一组可判断的工作包，而不是被卷入 Agent 的每一步思考。
held draft 是 Agent 工作空间里的关键模式。凡是会对外发送、修改生产数据、删除内容、触发付费资源、改变系统配置或影响他人的动作，都应该先停在草稿态。Agent 可以准备邮件、PR、发布说明、配置变更、数据修复脚本和执行计划，但最后一步要显式等待人批准。held draft 的价值不只是安全，它还让责任边界清楚：AI 负责准备和解释，人负责最终授权。
权限设计要和任务阶段绑定。研究、起草、重构建议、生成测试计划可以给更宽的探索空间；写入仓库、调用外部 API、发布内容、关闭工单、修改账务数据则需要更窄的权限和更强的审计。不要只问“Agent 能不能做这件事”，还要问“它在哪个阶段能做、做到哪一步必须停、结果如何被复核、失败后能不能回滚”。
一个实用的 Agent workspace 可以从几类对象开始建模：
- Agent：名称、职责、可用工具、权限范围、当前状态。
- Task：目标、输入、验收标准、截止条件、阻塞点。
- Draft：准备发布或执行的内容，默认不直接生效。
- Inbox：等待人处理的工作包，区分信息、审核、批准和补充输入。
- Audit log：记录 Agent 看过什么、改过什么、调用过什么工具、为什么做这个判断。
- Memory：可复用的项目知识、偏好、规则和历史决策，和临时上下文分开管理。
这种设计会把 Agent 从“会说话的工具”变成“有边界的同事”。人不需要盯着每一步，也不会失去最终控制权。Agent 可以连续执行、主动整理、形成草稿和交接包；人只在方向选择、权限升级、对外发布和不可逆动作前介入。协作效率来自这条边界，而不是来自完全自动化。