上周加入的这个项目——把一个AI智能体嵌入到现有工具的流程里，项目属于一期上线，新需求、优化、推广支持同步进行。

一开始我觉得分工应该很自然：工程负责老系统，算法负责智能体，接口一对就完事。但实际干下来发现，事情没那么想象中的简单。这类项目和从零搭一个AI产品不同，它有一层老系统在，很多工作天然落在两边中间，边界比想象中模糊得多。

花了一周时间跟两边分别聊，并结合我收到的项目资料，我整理出一个三层分工框架，记录一下。

一、为什么"嵌入型Agent"项目的分工特别容易模糊？

先说背景。市面上大部分AI项目的分工讨论，都是"从零建一个AI产品"的场景。但企业实际落地时，更常见的是另一种模式：把AI智能体嵌入到一个已经在跑的系统里。

这种模式有个特点——工程团队不是新拉的，他们对老系统非常熟，但对智能体的技术栈不太了解；算法团队对模型和Prompt很在行，但对老系统的架构、数据流、业务约束知之甚少。

两边各有一半信息，谁都没法独立把事情做完。而"中间地带"的工作项——比如智能体返回结果怎么解析、工具描述文本谁来写、业务规则怎么喂进Prompt——往往两边都觉得"不归我"或者"对方应该先出"。

这就是我说的分工模糊。不是谁推责，而是确实没人提前定义过这些交叉项。

二、我的三层分工框架

我试着把项目里的工作项分成三层。不是按"谁的技术栈"来分，而是按"这件事最终影响的是什么"来分。

第一层：系统对接层（工程主责）

这一层的核心问题是：智能体怎么稳定地接入现有系统？

这一层的交付标准相对明确：接口通不通、异常能不能兜住、监控看得到看不到。工程的判断依据是"系统跑没跑起来"。

第二层：智能体能力层（算法主责）

这一层的核心问题是：智能体本身表现得好不好？

这一层的交付标准是"效果好不好"——回答准不准、工具调得对不对、用户满不满意。算法的判断依据是模型层面的评估指标。

第三层：交叉协作层（双方共担）

这是最容易被忽略、也是最容易出问题的地方。

这一层没有简单的"归谁"，需要逐项确认谁先出初稿、谁审核、谁最终定版。

一个判断原则： 如果这个工作项的变动会影响模型输出质量，算法必须参与；如果变动会影响系统稳定性，工程必须参与。两边都影响的，就两边都坐到一起定。

三、PM在这个框架里做什么？

不是替两边做决定，而是拿着这个框架去做三件事：

1. 逐项确认归属。 对着框架里的每一项，跟双方确认：谁主责、谁配合、交接标准是什么。写下来，不要只口头说。
2. 盯住第三层。 第一层和第二层通常不会漏，工程做系统对接、算法做Prompt优化，各自都很清楚。容易漏的是第三层——那些"两边都觉得对方会做"的事情。PM的价值就是把这些空白地带变成明确的责任项。
3. 建立变更同步机制。 任何一方改了接口定义、Prompt结构、数据格式，对方必须同步知道。不需要PM来做技术决策，但PM要确保信息不丢。

四、一张启动检查清单

给自己整理了一份项目启动时用的检查清单，逐项跟两边过一遍：

• 智能体的嵌入点在哪？由谁定义接口规范？

• 请求和返回的数据格式是否双方确认？

• 模型超时/不可用时的降级策略是什么？谁实现？

• Tool Schema由谁出初稿？谁做语义调优？谁定版？

• 返回结果的格式约束是谁定义的？解析兜底谁做？

• Prompt里的业务规则从哪来？数据怎么更新？

• 日志和监控覆盖哪些指标？双方各负责哪些？

• 效果评估标准是什么？谁评估？多久评一次？

这类项目最大的坑，往往不是技术本身有多难，而是两边都以为对方在做、结果谁都没做的那些空白地带。PM能做的，就是在开工前花足够的时间，把这些地带一条一条摊开来，变成有人负责、有人验收的明确事项。