上一篇解决的是项目级问题：这个项目是否适合引入 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

过去几年，AI 给软件研发带来的变化，最先体现在代码生成上。从代码补全、文档生成和数据分析，到需求整理、方案设计、测试用例生成、缺陷定位，再到能够自主拆解任务、调用工具并持续执行的 AI Agent，AI 正在进入软件项目的各个环节。它带来的影响，也开始从“提升个人效率”转向“改变团队协作和项目运行方式”。当项目团队中出现 AI 编程助手、需求 Agent、测试 Agent、文档 Agent，甚至

​ 在上一篇《开发 Agent 前需要掌握哪些大模型基础》中，我们介绍了 Token、上下文窗口、消息角色、Structured Output、Function Calling、Embedding 与 Rerank 等基础能力。这些能力解决了“大模型如何接入应用”的问题，但当应用从一次问答升级为需要多轮推理、检索资料和调用工具的 Agent 时，开发者很快会遇到另一个问题：模型能力并不差，Prom