1. 项目概述从非结构化需求到形式化规约的智能跨越在软件工程和系统设计领域需求工程一直是个“老大难”问题。我们常常面对的是客户或业务方提供的几页Word文档、一堆会议纪要甚至是几段模糊的邮件描述——这些就是典型的“非结构化规约”。它们充满了自然语言的歧义、隐含的上下文和不完整的逻辑。而工程师的终极目标是将其转化为精确、无二义、可验证的“形式化规约”比如时序逻辑公式、状态机模型或者结构化的用户故事与验收条件。这个转化过程传统上高度依赖资深系统分析师的经验耗时费力且极易在传递中产生偏差。最近我花了大量时间研究如何利用大型语言模型来攻克这个痛点。项目标题“Towards an Agentic LLM-based Approach to Requirement Formalization from Unstructured Specifications”精准地概括了核心方向我们不再把LLM当作一个简单的文本理解工具而是将其塑造成一个具有“智能体”特性的系统主动、迭代、协作地完成从混乱自然语言到严谨形式化描述的蜕变。这不仅仅是文本转换更是一个需要理解、推理、质疑和精炼的复杂认知过程。简单来说这个思路就是打造一个“AI需求分析师”。它能够阅读你的需求草稿与你对话以澄清模糊点识别出其中的功能、约束、业务规则并最终输出结构化的、甚至部分可执行的规约描述。这对于提升早期需求分析的质量、加速设计迭代、以及为后续的自动化测试和验证打下基础有着巨大的实用价值。无论你是项目经理、系统架构师还是负责需求落地的开发工程师理解这套方法都能让你在项目起点就占据优势。2. 核心理念为何是“智能体”而非简单提示工程在深入细节之前我们必须先厘清一个关键概念为什么强调“Agentic”智能体化直接给LLM一个提示词让它“把这段需求转化成形式化描述”不行吗我的实践经验是对于简单、定义良好的句子或许可以但对于真实的、复杂的需求文档这种方法几乎总会失败。2.1 简单提示工程的局限性我最初尝试过直接提示。例如输入一段话“系统应在用户提交订单后如果库存充足则在30分钟内生成发货单若库存不足则通知用户并建议替代商品。”然后要求GPT-4输出为某种逻辑形式。结果可能得到一个看似正确的逻辑表达式但它往往无法处理以下情况隐含条件“库存充足”是否包括了“商品状态为上架”“用户提交订单”是否隐含了“订单支付成功”LLM不会主动追问。术语一致性前文称“发货单”后文称“运单”在形式化规约中是否视为同一实体边界情况“30分钟内”是指工作日还是包括节假日通知用户的“方式”是系统消息还是邮件这些缺失的信息会被简单忽略或随意假设。复杂逻辑交织当需求段落涉及多个业务规则和异常流程交织时单次提示的LLM很难生成一个自洽、完整的形式化体系。简单提示工程本质上是“一次性编译”缺乏交互、验证和迭代的闭环。而需求分析本身是一个需要不断沟通和确认的社交过程。2.2 智能体范式的优势“智能体”在这里指的是一种具备自主性、反应性、主动性和社交能力的软件实体。在我们的场景中一个LLM驱动的智能体应该能够主动提问像人类分析师一样识别需求描述中的模糊点、歧义处和缺失信息并向用户或其他智能体发起询问。分步推理将复杂的需求分解为多个子问题例如先识别参与实体和核心动词再梳理业务流程最后定义约束条件。利用工具调用外部工具例如查询领域知识库来确认术语定义或使用形式化语法检查器来验证生成规约的合法性。维护状态与记忆在整个对话或分析会话中记住之前已经澄清过的点、达成的共识以及做出的决策保证最终输出的一致性。协作与反思在多智能体架构中不同的智能体可以扮演不同角色如“需求挖掘者”、“逻辑验证者”、“规约书写者”通过辩论或协作达成更优结果。因此我们的方法不是设计一个完美的提示词而是设计一套智能体的“行为逻辑”和“协作机制”让LLM在这个框架内运作从而可靠地完成形式化任务。这标志着从“使用LLM”到“构建基于LLM的系统”的思维转变。3. 系统架构设计构建多角色智能体协作网络基于上述理念我设计并实验了一个多智能体协作架构。这个架构模拟了一个小型的需求分析团队每个智能体各司其职。下图展示了核心的工作流程与智能体间的交互关系但请注意实际实现中这些角色可能由同一个LLM实例通过不同的系统提示System Prompt来扮演或者由多个专门的微调模型担任。核心智能体角色定义需求解析与澄清智能体这是与原始非结构化文本直接交互的“前锋”。它的任务是进行初步的语法解析、实体识别和问题发现。它会输出一个带有标注和待澄清问题列表的中间表示。领域知识协调智能体它负责维护和查询项目相关的领域知识。当解析智能体遇到术语如“VIP客户”、“风控通过”时协调智能体会去查询知识库给出该术语在当前项目中的精确定义或者指出定义缺失需要人工补充。逻辑建模智能体这是核心的“分析师”。它接收经过初步澄清的需求片段运用逻辑思维将其转化为结构化的模型元素如用例、用户故事、业务流程步骤、业务规则等。它负责构建需求的逻辑骨架。形式化规约生成智能体这是“技术作家”。它将逻辑模型转化为目标形式化语言如线性时序逻辑LTL、计算树逻辑CTL、Z notation片段或特定的领域特定语言DSL。它需要精通目标语言的语法和语义。验证与一致性检查智能体扮演“质检员”的角色。它检查生成的形式化规约是否内部一致无矛盾是否与已澄清的需求意图相符以及是否符合形式化语言的语法规范。它可能调用形式化验证工具或进行简单的逻辑推理。工作流程详解整个流程是迭代和增量的而非线性瀑布式。初始化与输入用户提交一段非结构化需求文本。系统初始化一个会话并创建一个共享的“工作空间”用于存储中间产物、决策记录和待办问题。第一轮解析与问题生成需求解析智能体扫描文本进行命名实体识别找出系统、用户、数据对象等、动作提取和条件标注。同时它会产生一个“澄清问题列表”。例如对于“快速处理”这个描述它会提问“‘快速’的具体时间上限是多少秒”交互式澄清系统将问题列表呈现给用户或产品负责人进行回答。这些回答会被记录到工作空间并用于更新需求的理解。这里有一个关键技巧问题应该尽量是选择题或可量化的填空题而不是开放问答题以降低用户负担并提高信息精度。例如与其问“如何处理失败”不如问“当支付失败时系统应A. 自动重试三次 B. 立即通知用户 C. 记录日志并进入人工处理队列”逻辑建模与知识融合利用澄清后的信息逻辑建模智能体开始工作。它会与领域知识协调智能体交互。例如建模智能体试图建立一条规则“VIP客户订单优先处理”。协调智能体会查询知识库并返回“本项目‘VIP客户’定义为过去12个月内消费金额大于10万元且无投诉记录的用户。”建模智能体则将这个精确定义融入规则。规约生成与初步输出形式化规约生成智能体根据逻辑模型生成初步的形式化描述。例如将“用户登录失败三次后锁定账户15分钟”转化为LTL公式G((fail_login_attempt 3) - X(account_locked U (time_passed 15min)))这里G表示“始终”X表示“下一个状态”U表示“直到”是一个简化的示意。多轮验证与迭代验证智能体对生成的规约进行检查。它可能发现矛盾例如另一条需求说“管理员可随时解锁账户”这与“锁定15分钟”的自动过期可能冲突。验证智能体会将这个问题作为新的“待澄清项”抛回给工作空间触发新一轮的澄清或建模调整。这个过程循环进行直到验证通过或所有关键问题都已暴露并记录。输出与交付最终系统输出两份核心产物一份结构化的、半形式化的需求文档包含清晰的用例图、流程图、数据字典和带有精确条件的业务规则表。这是人类可读的中间件。一份机器可读的形式化规约文件用目标形式化语言书写可用于输入到模型检查器或测试用例生成工具。注意这个架构并非要完全取代人类分析师而是作为强大的辅助工具。它的目标是暴露歧义、保证一致性和提升效率。最终的需求决策权和模糊点的裁定权必须掌握在人类手中。4. 核心实现细节提示工程、工具调用与迭代控制有了架构蓝图接下来就是如何用现有的LLM API和框架将其实现。这里我分享几个关键模块的实现心得和踩过的坑。4.1 为每个智能体设计系统提示词系统提示词是智能体的“人格”和“职责说明书”。它必须清晰、具体并包含约束。需求解析智能体的提示词示例你是一个严谨的需求分析师。你的任务是从自然语言描述中提取结构化信息并找出模糊点。 请按以下步骤工作 1. 识别并列出所有提到的“实体”如系统、用户角色、数据对象。 2. 识别并列出所有“动作”或“事件”。 3. 识别所有“条件”或“约束”如“当...时”“如果...则”。 4. 对于任何模糊的描述如“快速”、“友好”、“稳定”或任何隐含的、未明确说明的信息生成一个具体的澄清问题。问题格式应为“【待澄清】[问题]”。 请以JSON格式输出包含字段entities, actions, conditions, clarification_questions。这个提示词规定了输出结构便于后续程序化处理。逻辑建模智能体的提示词示例你是一个系统架构师。根据已澄清的需求信息构建逻辑模型。 输入将包括实体列表、动作列表、条件列表以及一个记录了所有QA的澄清日志。 你的输出应包括 1. 用户故事格式作为[角色]我希望[目标]以便[价值]。 2. 业务流程步骤按顺序列出。 3. 业务规则表规则ID、触发条件、执行动作、例外处理。 请确保每一条规则都能追溯到澄清日志中的对应答案。这个提示词强调了“可追溯性”这是保证需求链路完整的关键。4.2 工具调用能力的集成智能体的强大之处在于能使用工具。我们需要为LLM配备“工具箱”。领域知识库查询工具可以是一个简单的向量数据库存储项目 glossary、架构文档片段。当智能体遇到术语时调用该工具的API进行语义搜索返回最相关的定义。形式化语法检查器对于生成的形式化规约可以调用一个轻量级解析器例如针对自定义DSL的ANTLR解析器或集成现有的LTL语法检查库来验证语法正确性。验证结果反馈给智能体进行修正。简单逻辑矛盾检测工具这可以是一组规则。例如检测规则表中是否存在直接矛盾的“条件-动作”对如条件A触发动作X另一条规则中条件A触发动作非X。这可以通过简单的模式匹配或定理证明器前端来实现。实现上可以利用 LangChain、LlamaIndex 等框架的“Agent”和“Tool”抽象也可以直接使用 OpenAI 的 Assistant API 中的“Function Calling”能力。核心是让LLM学会在合适的时机以合适的参数去调用这些工具。4.3 迭代循环与状态管理这是项目中最复杂的部分之一。如何控制智能体间的对话不陷入死循环或发散工作空间设计我使用一个共享的、结构化的数据对象在内存或数据库中作为工作空间。它包含original_text: 原始需求。clarification_log: 列表记录每个问题及其答案。current_understanding: 当前最新的逻辑模型。formal_spec_draft: 当前的形式化规约草稿。open_issues: 待解决的问题列表如验证发现的矛盾。decision_rationale: 重要决策的理由记录。循环控制逻辑设置一个最大迭代轮次如10轮防止无限循环。每一轮迭代后检查open_issues列表。如果为空且验证通过则流程结束。如果open_issues非空则根据问题类型将其路由给相应的智能体处理。例如一个关于术语定义的问题会路由给领域知识协调智能体和需求解析智能体。引入“优先级”和“新鲜度”机制。新产生的问题、阻塞性问题优先处理。对于长时间未解决的老问题可以升级为需要人工干预。关键技巧快照与回滚。在每次对核心模型current_understanding进行重大修改前保存一个快照。如果后续验证发现此次修改导致更严重的不一致可以回滚到上一个稳定状态并尝试其他修改策略。这模仿了人类的“试错”过程。5. 实战案例从一段模糊需求到形式化规则让我们通过一个简化但真实的例子走一遍核心流程。假设我们收到这样一段需求“用户可以通过上传一个Excel文件来批量创建客户账户。系统需要检查文件的格式正确性。如果文件格式错误要立刻告诉用户具体哪里错了。对于格式正确的文件系统处理每一行数据创建账户。如果某一行数据有问题比如邮箱格式不对不能影响其他行的处理要把有问题的行记下来最后一起报告给用户。整个过程最好快点。”5.1 解析与澄清阶段需求解析智能体工作输出实体用户系统Excel文件客户账户数据行。动作上传文件检查格式告知错误处理数据行创建账户记录问题行报告问题。条件/约束如果文件格式错误 - 立刻告知用户具体错误如果某行数据有问题 - 不影响其他行处理有问题行 - 记录并最后报告。澄清问题【待澄清】“检查文件的格式正确性”具体指什么请列出需要检查的格式项例如文件扩展名必须是.xlsx工作表名称列标题是否必须包含‘姓名’、‘邮箱’等【待澄清】“立刻告诉用户”是通过什么方式页面弹窗还是任务列表中的消息“具体哪里错了”需要详细到什么程度【待澄清】“数据有问题”具体包括哪些类型仅邮箱格式还是也包括姓名不能为空、手机号格式等请提供完整的数据验证规则列表。【待澄清】“最好快点”是否有可量化的性能要求例如“95%的文件处理应在5分钟内完成”假设我们作为产品负责人回答了这些问题格式检查项.xlsx或.xls格式第一行必须包含“姓名”、“邮箱”、“部门”列文件大小小于10MB。通过上传界面即时显示红色错误提示框列出所有格式错误项。数据验证规则邮箱需符合RFC标准格式姓名不能为空部门必须是预设列表中的值。性能要求90%的文件行数≤1000处理应在2分钟内完成。5.2 逻辑建模阶段逻辑建模智能体接收解析结果和澄清日志开始构建模型。用户故事作为业务管理员我希望批量上传Excel文件创建客户账户以便快速初始化系统用户数据。作为业务管理员我希望在上传时立即获知文件格式错误详情以便快速修正文件。作为业务管理员我希望即使部分数据行有误也能成功创建其他有效账户并获取错误汇总报告以便处理异常情况。业务流程用户选择Excel文件并触发上传。系统执行“文件级验证”格式、大小、列头。若验证失败系统在UI上即时显示错误列表流程终止。若验证通过系统逐行读取数据。对每一行数据执行“行级验证”邮箱、姓名、部门。验证通过的行异步执行“创建账户”操作。验证失败的行将行号、数据和失败原因记录到“错误列表”。所有行处理完毕后无论成功失败系统生成一个处理报告。报告显示成功创建账户数并附上“错误列表”详情。业务规则表规则ID触发条件执行动作例外/备注BR-F-01用户上传文件启动文件级验证BR-F-02文件扩展名非.xlsx/.xls记录错误“文件格式不支持”即时反馈BR-F-03文件大小 10MB记录错误“文件超过大小限制”即时反馈BR-F-04缺少“姓名”、“邮箱”、“部门”列头记录错误“缺少必要列头[列名]”即时反馈BR-F-05文件级验证通过开始逐行处理BR-R-01处理数据行启动行级验证BR-R-02邮箱格式无效记录行错误“邮箱格式无效”加入错误列表不影响其他行BR-R-03姓名字段为空记录行错误“姓名不能为空”加入错误列表不影响其他行BR-R-04部门不在预设列表记录行错误“部门‘{值}’不合法”加入错误列表不影响其他行BR-R-05行级验证通过创建客户账户异步执行BR-P-01所有行处理完毕生成处理报告报告需包含成功计数和错误列表5.3 形式化规约生成阶段形式化规约生成智能体根据逻辑模型生成形式化描述。这里我们选择一种可读性较高的“契约式”DSL领域特定语言作为目标。// 批量创建账户模块规约 Module BatchAccountCreation { // 数据类型定义 Data File {path: String, size: Bytes, extension: String, header: ListString} Data Row {line_num: Integer, data: MapString, String} Data ValidationError {type: EnumFileError, RowError, message: String, context: Row|File} // 前置条件 (Preconditions) Pre uploadFile(file: File) { file.extension in [.xlsx, .xls]; file.size 10 * 1024 * 1024; // 10MB RequiredHeaders [姓名, 邮箱, 部门]; forall h in RequiredHeaders: h in file.header; } // 后置条件 (Postconditions) 和 不变式 (Invariants) Post processFile(file: File) - (success_count: Integer, errors: ListValidationError) { if (!pre_uploadFile(file)) { // 文件级验证失败错误立即返回不创建任何账户 success_count 0; forall e in errors: e.type FileError; // 错误信息会即时显示给用户通过外部UI约定保证此处不形式化UI } else { // 文件级验证成功 Let validRows filter(rows, row_validation_passes); success_count count(validRows); // 行级错误被收集不影响成功行处理 forall r in rows where !row_validation_passes(r): exists e in errors where e.type RowError e.context r; // 性能约束非功能性需求 duration(processFile) 2 minutes with probability 0.9; // 当 rows 1000 } } // 辅助谓词 Predicate row_validation_passes(r: Row) { isValidEmail(r.data[邮箱]); r.data[姓名] ! ; r.data[部门] in PredefinedDepartments; } }这个DSL规约定义了数据类型、关键操作的先决条件和后置条件并将核心业务规则验证逻辑、错误处理逻辑、性能要求清晰地表达了出来。它比自然语言精确又比纯数学逻辑式更易于工程师理解。5.4 验证与迭代验证智能体会检查生成的规约语法检查调用DSL解析器确认语法正确。一致性检查检查是否存在矛盾。例如它可能会问Pre uploadFile中要求了文件大小Post processFile中也有性能约束这两者是否关联是否需要明确“当rows1000”时文件大小是否也有限制这可能会作为一个低优先级问题记录。与需求意图对齐检查将规约反向“翻译”成自然语言描述与原始需求和澄清日志对比看是否有遗漏或偏差。例如规约中明确表达了“行错误不影响其他行”通过forall循环和独立验证体现这与需求意图一致。经过可能的多轮微调我们最终得到了一份机器可读、逻辑严谨的形式化规约以及一份人类可读的详细逻辑模型。这为后续的数据库设计、接口定义、业务逻辑开发和测试用例生成提供了极其坚实的起点。6. 挑战、局限性与未来展望在实际推进这类项目的过程中我遇到了不少挑战也清醒地认识到当前方法的局限性。6.1 主要挑战与应对策略LLM的“幻觉”与稳定性即使在严格的提示词约束下LLM仍可能生成看似合理但不符合已有约束或领域常识的内容。应对策略加强验证环节。不仅用另一个LLM智能体验证更要依赖“工具”如语法检查器、规则引擎进行客观验证。采用“生成-验证-修正”的强反馈循环。复杂逻辑与长上下文当需求文档长达数十页时LLM的上下文窗口可能无法容纳全部信息导致遗忘或理解碎片化。应对策略采用“分而治之”策略。先让智能体对文档进行高层次摘要和模块划分然后针对每个模块进行独立的形式化最后再有一个“集成智能体”负责处理模块间的接口和全局一致性。利用向量数据库进行长期记忆和相关信息检索也是一个方向。领域知识依赖性强智能体的表现严重依赖于领域知识库的完备性和准确性。知识库构建本身就是一个大工程。应对策略从“小而精”的特定领域开始如金融交易中的特定合规规则逐步积累知识库。设计智能体能够主动识别知识缺口并请求人类专家补充的机制。评估指标难以确定如何衡量生成的形式化规约的“好坏”正确性、完整性、简洁性之间如何权衡应对策略目前采用“专家评审”结合“下游任务效用”来评估。例如将生成的形式化规约输入到测试用例生成工具中看生成的测试用例是否有效覆盖了需求场景。这是一个间接但实用的评估方法。6.2 当前局限性并非全自动它本质是一个“人在环路”的增强智能系统。对于高度创新、模糊或涉及深层领域专业知识的决策仍然需要人类专家的介入。启动成本高为特定组织或领域定制一套可用的智能体工作流和知识库需要相当的初始投入。形式化语言的门槛输出形式化规约的价值取决于团队是否有能力理解和利用它。这要求团队成员具备一定的形式化方法基础。6.3 实用建议与心得如果你也想在团队中尝试引入类似方法我的建议是从痛点出发小范围试点不要试图一次性处理整个产品的需求文档。找一个逻辑复杂、容易出错的典型场景如订单状态机、权限校验规则作为试点。优先追求“暴露歧义”在初期不必强求生成完美的形式化输出。能把需求中所有隐藏的假设、模糊的表述都挖出来形成清晰的澄清问题列表其价值就已经非常巨大了。人机分工明确让智能体做它擅长的快速解析、发现不一致、生成草案、检查语法。让人做他擅长的做出业务决策、裁定模糊地带、提供领域知识。积累属于你们自己的知识库在试点过程中所有被澄清的术语、定义的业务规则都要系统地沉淀到知识库中。这是项目最重要的资产会随着时间产生复利效应。这个领域正在快速发展更强大的多模态LLM、更高效的智能体协作框架、与需求管理工具如Jira, Doors的深度集成都是值得期待的方向。核心思想不变将人类分析师从繁琐、重复的信息梳理和一致性检查中解放出来让他们更专注于创造性的需求探索和价值判断。这条路虽然充满挑战但每一步都指向更高效、更可靠的软件构建起点。