最近使用 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

在前面的文章中，我们已经介绍了大模型应用开发所需的基础知识，以及 Prompt Engineering 和 Context Engineering 如何帮助模型理解任务、组织信息并形成判断。然而，理解问题并不等于完成任务。模型可以识别用户想查询天气、分析销售数据或创建审批任务，但如果不能连接天气服务、业务数据库和审批系统，它最终仍然只能生成文字。Function Calling 解决的正是从“语言

在企业办公、合同管理、知识库、档案管理和云文档等系统中，文件既是业务信息的主要载体，也是 Agent 执行真实任务时必须面对的对象。用户可以直接向 Agent 提出：打开这份合同，定位付款条款；把一批 Office 文件统一转换成 PDF；合并这些 PDF，并添加“内部资料”水印；提取文档正文，生成摘要并写入知识库；清除 Word 中的批注和修订，生成正式版本。大模型能够理解这些自然语言指令，但并

 过去一轮 AI 办公主要解决的是内容生成问题：用户在聊天框中提出要求，AI 返回一段文字、一张表格或一份演示文稿，再由用户复制、下载和修改。腾讯 WorkBuddy 展示的则是另一种产品形态——以 Agent 为统一入口，把任务、项目、知识、文件、连接器和在线编辑能力组织到同一个工作环境中，使 AI 不只是回答问题，而是参与完整的办公流程。对于希望建设企业级 AI Office 的团队而言，Wo

在本系列的开篇中，我们提出了一个基本判断：AI 对软件项目的影响，正在从个人效率工具扩展到项目运行方式。项目经理面对的管理对象，也开始从人员、任务和资源，延伸到模型、AI 工具、Agent、知识库、自动化流程以及由它们生成的各种成果。进入第一部分“趋势与基础概念”，首先需要进一步回答一个问题：AI 究竟改变了软件项目的哪些地方？提到 AI 与软件研发，很多人首先想到的仍然是代码补全、代码生成和 V