98配资官网-深圳配资-全国配资网-按日配资炒股

股票上的杠杆但若要在现实业务中胜任复杂任务

随着AI大语言模型技术的迅猛发展，我们正处于一个激动人心的技术拐点。

但当最初的惊艳褪去，一个更加实际且复杂的问题浮出水面：

不是仅仅做一个“带聊天框”的传统软件，我们要如何将大模型真正嵌入到业务系统中，构建出“原生智能”的产品体验？

本文将围绕我们近期在合同场景下的智能系统设计探索，尝试梳理并分享关于构建大模型原生（LLM Native）产品的一些思考。

图片由AI生成

核心理念的转变：我们如何定义大模型与工具的关系

在传统软件系统中，“工具”是为人设计的。

而在LLM Native的语境下，工具的含义正在发生转变：它既是为人服务，也必须为模型服务。

展开剩余89%

我们认为，“大模型工具”这个词具有关键性的双重含义：

01为大模型设计工具（Tools for the LLM）

今天的大模型已具备广泛的推理、生成、分析能力，但若要在现实业务中胜任复杂任务，它仍然需要借助外部能力。

这催生了一个新的工具体系：用于补足大模型能力的插件化模块。典型如：

向量数据库：用于RAG场景，作为模型的动态知识库；

除去向量数据库这一类非常典型的提供额外能力的大模型工具外，还有一类“大模型工具”也值得关注，它们不仅能补充或扩展大模型的典型功能，更能对其核心能力进行有效增强，更有趣，也更有想象空间。典型代表如：

Sequential Thinking MCP：提供了一个类似于TodoList的工具给大模型使用，为模型提供任务规划与记忆支持，使其在复杂任务中保持更高准确率和一致性。就相当于我们不需要做任何事情，只需要给大模型一个简简单单的记事本并让他遵循记事本的使用流程来进行他的工作，大模型能力就能够有一个明显提升。

此时类比到我们人身上，我们会发现即使智能化如人类，我们仍然需要诸多的工具来帮我们来完成各种不同的任务；例如为了更好完成整个企业的合同管理，我们就需要一个专业化的智能合同管理产品。所以为了让大模型能够完成诸多复杂的实际业务场景下的任务，我们也需要为大模型提供各种不同的工具。

02对模型友好的工具（LLM-Friendly Tools）

这一层含义也是当前如何做好工具的智能化非常重要的一点，也是非常容易被忽视的一点。我们必须认识到，大模型时代下的工具想要做到智能化就不仅要服务于人，也要服务于大模型。

目前，绝大多数软件工具都是为人类用户设计的，它们依赖于人的视觉、理解力和领域知识。当我们将这些“为人类设计”的工具直接丢给LLM时，效果往往不尽人意。根本原因不在于LLM不够聪明，而在于工具本身对LLM“不友好”——它没有提供足够的上下文。

Shopify CEO Tobi Lutke的一句话精准地指出了核心所在：

"The art of providing all the context for the task to be plausibly solvable by the LLM." （为大模型提供所有必要的上下文，使其能够合理地解决任务，这本身就是一门艺术。）

一个优秀的LLM Native产品，必须在设计之初就思考：如何让我的系统能被LLM“理解”和“操作”？

图片由AI生成

在既有产品上叠加大模型，为什么不行？

所有的工具都是为了能够更好、更高效地解决实际的业务问题，一个好的大模型产品，终极目标是能更高效、更优质地解决实际业务问题。我们当前有了很多能力很强、能解决诸多问题的通用大模型产品，但是在专有的领域和业务场景下，使用起来仍然会有诸多问题。

让我们以法律领域的合同起草和审查为例，首先我们先来看在企业中起草一份合同时，往往是怎样一个流程（简化示意）：

我们往往不会完全从头开始起草，而是首先去查看是否有已有的模板、范本、历史合同可以直接用来或者修改后进行合同起草；若没有对应的模板或者范本，我们往往需要根据企业内部的管理规定、规范制度和积累下来的条款库来去进行合同起草；起草的过程中，我们往往还需要参考业务相关的信息（例如项目文件、招投标信息、企业信息等）来去补充合同内具体的业务信息。

那么假设我们直接使用强大的DeepSeek对话能力来辅助法务人员工作，会遇到哪些挑战。

上下文缺失：一份专业的合同远不止是文本。LLM在起草时，需要知道公司的合同模板库、起草规范、历史相似合同；在审查时，需要理解合同的交易背景、业务需求以及内部的风控审查要点。没有这些上下文，LLM只能给出通用、宽泛、甚至错误的建议。能力缺失：LLM可以生成条款文本，但它无法直接在你的系统里“新建一份合同草稿”，也无法将业务信息填写到我们的word文件、审批流表单中。这些动作需要人来“为大模型服务”，手动执行。任务规划缺失：一个完整的“合同起草”任务，包含上述多个子步骤，用户需要自己来规划和驱动整个流程。并且这一流程往往在不同企业下会有不同的规定和要求。

上面的这几个挑战，既揭示了在业务场景上直接叠加大模型对话会导致的问题，但也恰恰指明了如何做好“大模型原生产品”的方向。

图片由AI生成

如何做一个好的大模型原生产品？ ——我们的思考

针对上述挑战，一个优秀的LLM Native产品必须在三个层面进行构建：

上下文信息的高效获取和提供：系统必须能自动、精准地将当前任务所需的所有相关信息（如页面数据、业务规范、历史文档）并且恰当地提供给LLM。上下文环境（工具内）的直接交互：LLM的能力不应止于生成文本，它必须能直接在应用内执行操作（如起草合同文件、编辑表单、发起合同审批等），实现“所想即所得”。提升复杂任务的规划能力：产品应辅助LLM和用户进行任务拆解和规划，将复杂目标分解为清晰、可执行的步骤。

在此一个关键问题是：哪些是大模型能力自身发展能解决的，哪些是应用层面必须解决的？

任务规划能力可以被LLM的发展部分解决，模型会越来越擅长分解任务。但如果企业有自己独特的、规范化的任务流程，这依然属于需要外部提供的“上下文信息”。而上下文获取和环境交互，则几乎完全无法依赖通用大模型自身的发展来解决。即使是AI浏览器这类通用工具，也会需要目标业务系统本身能以一种结构化的、对大模型友好的方式，暴露其上下文信息和交互接口。

结论是：构建大模型原生产品的核心，更在于应用本身的设计，而非仅等待一个更强的“超级模型”就能达到。

AI原生的合同管理该如何落地？

如果要真正把合同管理系统做成大模型原生（LLM Native）的形态，我们认为至少需要在三个关键层面展开探索：上下文获取、上下文交互、复杂任务规划。

01上下文获取：如何让LLM“看懂”业务

一个真正智能的系统，不应依赖用户手动输入全部上下文，而是能够在后台自动完成“业务语境感知”。这包括：

动态页面与用户上下文：当用户在不同页面、查看不同数据时，系统应能无感切换上下文，让模型始终知道用户“此刻在做什么”。深度业务上下文：除了界面信息，还应包括制度文件、历史合同的审查记录、关联合同的履约信息等。这些信息必须被结构化获取并动态提供给模型，帮助其在具体任务中做出更贴近业务的判断。

02上下文交互：如何让LLM“动手”操作

大模型原生系统不能只是“给答案”，它还应该能在上下文环境里直接完成操作：

前端与后端能力封装：模型可以调用工具来执行各种操作，比如编辑表单、跳转页面、创建数据、发起审批、提交意见等。用户确认与版本回退：关键操作仍需人类确认，并记录操作历史，以确保流程安全可控。

03复杂任务规划：如何让LLM“思考”周全

合同管理往往包含多环节、复杂链路，因此系统需要帮助模型具备拆解与规划能力：

TodoList任务流：类似Sequential Thinking，模型在面对复杂请求时会生成一系列清晰的子任务。例如：判断是否存在合适的合同模板；如无模板，则调用制度文件和条款库；生成合同大纲，供用户确认；生成初稿；上传系统，发起审查。这样的过程让用户能随时引导和修正，提升整体可控性。动态Agent机制：针对特定场景，系统应能动态组合工具，调用专职智能体（Agent）来执行任务。企业甚至可以根据自身业务要求自定义配置Agent，实现“配置即智能体”（Configuration as an Agent）。

需要特别注意的是：工具不是越多越好。模型调用工具的能力并非无限，过多的工具可能反而干扰判断。系统应能动态管理、优化工具集，只在需要的上下文中提供最相关的工具，以保证执行的精准度。

结语与展望

我们认为，不仅是“给予模型的工具”，更要设计“对模型友好的工具”，这才是构建大模型原生产品的关键。

在这个方向上，设计不只是简单叠加功能，而是要从根本上重构应用架构：

如何让系统在任务中“自动感知上下文”；如何让模型能够“直接动手执行”；如何在复杂任务里“思考并拆解路径”。

当这些要素结合起来时，大模型不再是一个外部的聊天机器人，而会逐渐成为一个嵌入业务流程的“超级同事”。

图片由AI生成

这只是我们对于合同管理相关设计理念的一次简单复盘探讨。接下来，一个深度融入我们几年来对于合同业务场景理解及原生AI产品设计思考的产品也即将揭晓。敬请期待！

发布于：北京市

98配资官网-深圳配资-全国配资网-按日配资炒股提示：文章来自网络，不代表本站观点。