上一篇讨论了 AI 如何把访谈记录、会议纪要、聊天消息和历史资料整理成需求候选清单，从而提升需求分析效率。效率提升以后，新的问题也随之出现：AI 可以很快生成一份结构完整、措辞专业的需求文档，但文档完整并不代表需求已经被确认。传统需求文档的问题通常比较直观，比如遗漏、描述不清或结构混乱；AI 参与以后，更常见的问题是模型会主动补齐缺失信息，把推测、经验和常见做法一起写进文档。如果这些内容没有经过

进入需求阶段以后，AI 最容易体现价值的地方，并不是“帮忙写一份需求规格说明书”，而是把过去大量耗费在整理、归纳、拆分和交叉检查上的工作压缩下来。一个真实的软件项目，需求往往并不是以完整文档的形式出现。客户可能在会议上描述业务，在微信群里补充规则，在旧系统截图里说明现状，又在后续评审中修改细节。需求人员真正耗费时间的，通常不是打字，而是把这些零散信息还原成一套一致、可讨论、可开发、可验收的需求。A

前面的文章，我们已经分别介绍了 Context Engineering、Function Calling、Structured Output、RAG、Agent Loop、状态机和 Memory。这些能力单独使用时并不复杂。真正进入企业应用以后，问题变成：怎样把这些能力组合成一个真正可以被员工使用的知识助手？早期企业知识助手通常可以概括为：上传文档 → 建知识库 → 用户提问 → RAG → 大模

最近使用 Codex 时，遇到了一个比较容易让人困惑的情况：9 月 17 日使用了一张官方赠送的 Codex 重置卡，19 日 ChatGPT 套餐正常自动续费，到 20 日把额度用完后，却发现 Codex 并没有因为 19 日已经续费而重新恢复到 100%。与此同时，之前又遇到过另一种情况：明明 Codex 还有剩余额度，却突然自动恢复到了 100%。如果把“套餐续费”“每周额度”“重置卡”“自

上一篇我们使用 State Machine 解决了一个重要问题：当前这一次任务执行到哪里。 但状态机并不会让 Agent 真正“认识”用户。假设用户连续几周都在使用同一个需求分析 Agent，并多次说明：输出需求时使用三级结构；偏好简洁的需求描述；项目后端使用 Java 21；所有接口设计默认考虑多租户。如果每次新建 Session 后都需要重新告诉 Agent，这个 Agent 虽然拥有 Sta

前面几篇已经逐步解决了项目启动阶段的几个关键问题：项目是否适合引入 AI、哪些任务值得交给 AI，以及 AI/Agent 在项目中能够获得怎样的数据、工具和执行权限。当这些问题逐渐明确以后，最后还剩一个非常现实的问题：项目到底应该使用什么 AI？很多团队最初引入 AI 时，工具选择主要取决于个人习惯。项目经理用 ChatGPT 或 DeepSeek 整理资料，开发人员自己选择 AI 编程工具，测试

上一篇介绍主流 Agent Framework 时，我们已经看到，简单 Agent 的核心仍然是 Model → Action → Observation → Model。模型根据当前上下文判断下一步，调用 Tool 获取结果，再结合新的 Observation 继续决策。这种自由循环非常适合搜索、研究和 Coding 等开放式任务，但进入需求分析、合同审核、审批、财务操作等企业场景后，系统关注的

2026 年 8 月 26 日，The Document Foundation 正式发布 LibreOffice 26.8。这个版本最受关注的变化包括 Paragraph Composer、复杂文字系统支持、OpenType Variable Fonts、文档交换保真度以及大文档性能优化。官方甚至直接把这一版本的三个重点归纳为：排版质量、全球书写系统支持和与其他 Office 软件交换文档时的保真

上一篇讨论了项目启动阶段如何给 AI 分任务：重复、标准化工作可以让 AI 多做，可生成、可验证的工作可以采用“AI 生成 + 人确认”，复杂判断仍由人主导，责任决策则继续由人承担。但当任务真的交给 AI，特别是从普通聊天工具进一步发展到能够访问代码、调用工具和执行操作的 Agent 后，一个更现实的问题随之出现：AI 可以参与，但到底可以参与到哪一步？例如 Dev Agent 可以读取整个代码仓

2026 年 8 月 26 日，The Document Foundation 正式发布 LibreOffice 26.8。官方将这一版本的重点概括为三个方向：更专业的排版、更深入的全球书写系统支持，以及更好的跨 Office 文档交换保真度，同时还特别强调 LibreOffice 本身不内置生成式 AI。其中最受关注的变化，是 Writer 新增加的 Paragraph Composer（段落排

上一篇，我们没有使用任何 Agent Framework，而是手写了一个最小 Agent，最终把 Agent 的核心压缩成一句话：Model → Action → Observation → Model。 那段代码并不复杂，但只要继续往真实项目推进，很快就会遇到新的问题：Messages 越来越长怎么办？Tool 越来越多怎么管理？任务中断如何恢复？RAG 放在哪里？如何做流式输出、人工审批、重试

上一篇解决的是项目级问题：这个项目是否适合引入 AI，以及数据、工具、工程和治理条件是否具备。 一旦确定项目可以使用 AI，下一步就不能继续停留在“要不要用”的讨论上，而要进入更具体的任务层：项目中到底哪些工作交给 AI，哪些由 AI 辅助，哪些仍然必须由人负责？这其实是 AI 时代新增的一次任务分工。过去项目经理主要考虑“谁来做”，现在还需要进一步考虑“由人做、AI 辅助做，还是交给 Agent

在国产化、信创以及政企办公软件替代持续推进的背景下，WPS Office 在国内企业和政府机构中的使用越来越普遍。对 OA、合同管理、档案、知识库、网盘等系统来说，过去只处理 DOC、DOCX 已经不够，、 正逐渐成为必须面对的真实文件格式。真正复杂的地方在于，WPS、WPT 并不像 DOCX 那样拥有成熟、统一、公开的 OOXML 规范和完整的开源解析生态，简单文件可能可以直接交给转换组件处理，

前面的文章，我们已经分别介绍了 Context Engineering、Function Calling、Structured Output 和 RAG。这些能力单独看并不复杂，但真正进入 Agent 开发后，还需要回答一个问题：谁来决定什么时候调用模型、什么时候执行工具、拿到工具结果以后是否继续，以及什么时候结束任务？答案就是 Agent Loop。从这一篇开始，我们正式进入“第一个 Agent

过去的软件项目启动，重点通常放在业务价值、技术可行性、预算、周期、资源和风险上。只要目标基本清楚、技术路线可行、人员能够到位，项目就可以进入后续需求和设计阶段。AI 进入软件研发以后，这套判断标准仍然有效，但已经不够完整。因为同一个项目中，AI 可能只是帮助项目经理整理材料，也可能参与需求分析、代码生成、测试、文档编写，甚至以 Agent 的方式直接调用工具、修改代码或执行任务。AI 参与程度不同

上一篇介绍 Structured Output 时，我们解决了一个问题：模型生成的结果，怎样可靠地交给程序处理。 但真正开发 Agent 时，还会遇到另一个更基础的问题：模型怎样获得自己原本并不知道的知识？例如，企业内部有产品文档、制度、合同、项目资料和会议纪要，这些内容并不存在于通用大模型的训练数据中；即使是公开信息，也可能已经发生变化。如果用户问： “公司目前北京地区的差旅住宿标准是多少？”

AI 编程、代码生成、测试生成、文档生成和 AI Agent 快速进入软件研发之后，一个很自然的问题是：既然开发方式越来越快、越来越自动化，传统瀑布型项目是不是已经不适合了？如果只看“代码怎么写”，这个判断似乎有一定道理。AI 可以把过去需要几天完成的原型、接口草稿、测试用例甚至部分功能代码压缩到几个小时，传统按照“需求完成后再设计、设计完成后再开发”的严格串行方式，确实容易显得笨重。但软件项目并

上一篇介绍了 Function Calling：让大模型能够根据用户目标选择工具、生成参数，并调用数据库、业务 API 或其他程序能力。但 Agent 真正接入业务系统后，还存在另一个同样重要的问题：模型产生的结果，怎样可靠地交给程序处理？例如用户告诉 Agent：请创建一个任务：8 月 14 日前完成华东区客户回访方案，优先级高，负责人张晨，预算不超过 5000 元，并拆成整理客户名单、执行回访

引言：当 AI 不再只是坐在工具栏里在上一篇文章中，我们讨论了 AI 正在改变需求、设计、开发、测试和项目协同，而不只是提高代码生成速度。当 AI 的能力继续向任务规划、工具调用、代码执行和结果验证延伸，一个更深层的变化开始出现：AI 不再只是项目成员使用的工具，而是逐渐成为项目流程中的参与者。早期的 AI 更像一个随叫随到的助手，能够回答问题、生成内容，却不会持续跟踪任务；今天的 AI Agen