我长期从事 Java 和企业软件开发。过去最熟悉的事情，是把相对模糊的业务需求拆成接口、表结构、规则、流程和异常分支，再把它们落到可以测试、部署和维护的系统里。
最初接触大模型时，我把 AI 应用想得很简单：接入一个模型接口，写一段提示词，加一个聊天页面，让系统返回一段自然的答案。这个过程并不难，也很容易让人觉得，AI 应用开发主要是模型选型和提示词设计。
真正参与项目后，这种理解很快被修正了。模型能回答问题，和系统能够稳定地完成任务，中间还有很长的一段路。也正是这段路，让我开始认真研究 Agent。不是因为它是一个新概念，而是因为它把模型放进真实系统后，很多原来熟悉、但不能跳过的工程问题都重新出现了。
我以前熟悉的软件开发
传统企业系统的执行链路通常比较明确：用户发起请求，接口接收参数，业务逻辑按照既定规则处理，数据库或外部系统提供数据，最后返回相对确定的结果。
用户请求
→ 接口
→ 业务逻辑
→ 数据库或外部系统
→ 确定性结果
这套方式没有过时。企业里的权限控制、审批流程、数据落库、任务调度和审计追踪，仍然依赖可预测、可验证的行为。
长期在这样的环境里工作，会形成一些很朴素的习惯：先澄清输入和输出，再定义边界；把复杂问题拆成可测试的模块；为异常准备兜底；让重要状态可以追踪；需求变化时控制改动范围。进入 AI 项目后，这些习惯没有失效，只是系统里多了一个不总能给出确定结果的模型。
一开始，我把 AI 应用想简单了
模型接口、提示词和聊天页面当然是开始，但它们更像一次能力验证。一个 Demo 能正确回答几次问题，只能说明模型在某些输入下表现不错，不能说明它能进入真实业务流程。
用户问一个看似简单的问题，系统可能先要识别身份，再决定他能看哪些数据；模型可能需要查询、检索、计算，或者生成文件；执行过程中还要处理超时、重试、流式返回和中途取消。最后用户需要的也不一定是一段文字，可能是已保存的结果、一份文件，或者一条等待人工确认的操作。
到这一步，模型不再是整个应用，而是系统里的一个环节。它适合做理解、归纳、判断和生成，但不能替代所有确定性的业务规则。
真正做项目以后，问题变了
之前做一个企业问答类项目时，最开始大家关注的主要是模型能不能把问题回答对。真正联调以后，问题很快就变了：这个用户能不能看到这部分数据？查询失败时该返回什么？一个任务执行几分钟，前端怎么知道进行到哪一步？模型调用工具后，执行过程和结果要怎么记录？
这时我才意识到，做的已经不是“给模型套一个聊天页面”，而是在重新做一套软件系统，只是其中多了一个不那么确定的模型。后面接触数据分析、报告生成、知识检索和文件处理等场景时，这种感觉反复出现：用户拿到一句答案，不代表任务已经完成。查询、计算、生成文件、调用系统、保存结果、人工确认和状态查询，往往才是事情真正落地的部分。
困难也不在于让模型说出一句话，而在于如何让它在正确的边界内做正确的事。身份和权限如何进入一次请求？模型怎样访问数据而不越权？工具参数如何校验，副作用如何限制？上下文变长后如何保留真正有价值的信息？任务失败时又怎么定位和恢复？
这些问题最后还是回到了软件架构、权限、状态管理、异常处理、安全、日志和可观测性。模型提供智能，但软件工程决定这种智能能不能稳定进入业务系统。这句话不是说模型不重要，而是说模型只有放进合适的系统设计里，才可能被可靠地使用。
我也重新理解了“可用”的含义。传统系统里，一个接口是否可用，通常可以看输入、输出、异常和性能；AI 应用还要看回答是否贴合上下文、工具是否用对、失败时用户是否知道发生了什么。一次看起来合理的回答，如果无法追溯依据、无法安全执行下一步，或者出了问题没有恢复路径，我觉得这个功能还不能算真正可用。
为什么后来开始关注 Agent
我理解的 Agent，并不等于一个“会自主思考”的聊天机器人。更实际地说，它是以模型做理解和判断，结合上下文、工具、流程和业务系统完成任务的一种运行方式。
当问题从“让模型回答”变成“让系统完成一项任务”时，我开始关注 Runtime、工具调用、流程控制、沙箱和执行记录这些问题。名字本身并不重要，它们都在解决项目里遇到的实际问题：一次任务怎么管理，外部操作怎么控制，复杂流程怎么约束，脚本怎么安全执行，出了问题怎么追踪。
模型可以负责理解模糊意图、归纳信息和提出建议，但系统仍要明确哪些动作可以自动完成，哪些只能建议，哪些必须由人确认。尤其涉及业务操作、数据访问和资源消耗时，不能把边界完全交给模型临时决定。
传统软件工程并没有失效
后来我越来越觉得，AI 应用不是把原来的软件工程推翻重来。模型只是让系统多了一种处理问题的方式，而真正要把它放进企业系统里，很多问题还是要靠原来的工程设计解决。
权限、接口、数据库、日志、异步任务、状态管理、异常处理、系统集成、安全和可观测性，在 AI 项目里反而更显眼。模型输出有不确定性，就更需要清楚的边界和失败兜底；任务可能持续很久，就更需要状态和异步处理；模型能调用外部工具，就更需要权限、审计和安全控制。
Java 仍然是企业系统里常用的工程语言。过去做企业开发时积累的系统集成、稳定性和可维护性经验，能帮助我少走一些弯路。但另一面也很清楚：模型、Python 工具链、评估方法、数据治理，以及怎样面对模型的不确定性，都需要继续学习。我并没有完成什么“转型”，只是开始在原有经验之外补上相关技术知识。
我现在怎么看这件事
现在再回头看，我开始研究 Agent 的原因其实很简单。真正做 AI 项目以后，我发现很多问题已经不能只靠调用一次模型来解决。模型很重要，工程设计同样重要；有意思也困难的地方，正是在两者之间。
我现在仍然在边做边学，很多设计没有标准答案。但至少有一点越来越明确：把模型接进系统只是开始，怎样让它在真实场景里安全、稳定地发挥作用，才是后面更值得花时间的事情。
