AI 提出建议，
由人来批准
智能体是 Onplana 三区决策模型中的建议区。在三种操作中，AI 对已有数据提出修改建议，在旁边展示证据，并等待人来接受或驳回。风险提醒、资源调整、建议的进度计划。
提议与批准的模式
建议区的所有操作都具有相同的形式。AI 提供证据；人来做修改。AI 在搜索、分析和起草时自主工作；在需要修改已承诺的数据时则有所克制。
这种形式就是提议与批准模型。正是这种纪律，让智能体的工作在真实 PMO 的规模下保持安全。没有它，智能体要么承诺过多（自行修改已有计划，遇到第一个边缘情况就失败），要么给得太少（只返回文本，从不行动）。一个季度下来节省的大部分时间都体现在建议区，因为 AI 负责分析和起草，人负责判断。
界限在代码中，而不在提示词中。措辞不当的提示词无法让 AI 在没有人批准的情况下应用一条建议。检查在服务器上进行，并不依赖于对良好提示词设计的信任。
建议区的三种操作
针对每一种：AI 提议什么、旁边显示哪些证据，以及批准是什么样子。
风险提醒
建议
AI 把某个任务或里程碑标记为有风险，并指出引发它的具体信号
旁边的证据
列出提醒背后的任务：延误或受阻的工作、没有负责人的任务、在等待其他任务的工作，以及距离完工日期还剩多少时间
批准
项目经理把风险加入登记册、驳回它，或把它分配给负责人
资源调整建议
建议
AI 建议某个任务应由谁负责并说明原因，例如把工作从当周超出容量的人转给有余量的人
旁边的证据
被建议人员包含该任务后的那一周：其容量、已承诺的其余工作、该任务所占的份额，以及加上它后是否超出容量，在建议旁边供审阅者查看
批准
项目经理接受后，任务按建议分配；或者驳回，什么都不会改变
建议的进度计划
建议
给出一个截止日期，AI 会为每个任务建议开始和完成日期，并可以根据每个人的工作负载对计划进行平衡
旁边的证据
每个任务的建议日期、计划将完成的日期，以及任何警告或截止日期无法满足的原因
批准
在项目经理应用之前什么都不会改变，并且在应用之前会先为计划的原样保存一条基线。比较整个项目组合的情景属于情景规划，适用于Enterprise 方案及以上，而且不使用 AI
以及排除区
有些决定不交给 AI。Onplana 对其中大多数没有相应的功能；在存在相关界面的地方，AI 以使用者的权限行事，不能超越它们。
财务承诺
AI 可以总结预算的消耗节奏，并标出支出超出批准额度的风险。它不能批准采购订单、签署合同，也不能更改已批准的预算数字。
基线批准
应用建议的进度计划之前，会先为计划的原样保存一条基线，因此不会丢失任何东西。而批准本身，即宣布“这就是正式计划”的行为，属于人。
绩效评估
Onplana 保存已完成任务的数据、评论历史和分配模式。AI 从不把它们汇总成对某个人的评估。记录在那里；判断由你来做。
供应商选择
AI 可以总结一份投标答复。授标的决定不是 AI 的产出。
收尾决定
关闭项目、归档项目组合或解除某人的角色，都是人的行为。AI 可以指出这些做法可能是合理的；但不能执行它们。
原则是：当一个错误的决定会带来任何撤消按钮都无法弥补的法律、财务或个人代价时，AI 不采取行动。排除区很小、边界清晰，正是因为划错边界的代价是不对称的。
你拒绝的建议会怎样
接受和驳回以同样的方式衡量。其中一项如今已经在影响 AI 接下来的建议。
接受率会被衡量
Onplana 记录 AI 建议被接受或驳回的频率，让你看到某类建议是值得保留，还是只在消耗注意力。建议不会自行应用，也没有任何设置能改变这一点。建议区的每条建议都在等待一个人。
你驳回的内容让风险检测更谨慎
在风险检测中，驳回会在你的所有项目中计数并反馈给检测器：你的团队一再驳回的类别，只会在项目数据明确支持时才被标出。它是引导，而不是屏蔽，因此真正相关的风险仍然可以出现。
这种模式如何保持诚实
以下规则适用于建议区的所有界面。
默认附带证据
每条建议都在旁边显示它所依据的数据。要求项目经理相信 AI 对他自己项目的无出处断言，第一次答错就站不住了。
批准位于工具层
在服务器上。一条建议被保存为待处理的建议，只有人在服务器上接受才会应用它，因此措辞不当的提示词无法绕过检查：验证在服务器代码中，而不在于对良好提示词设计的信任。
每一步都有记录
一条建议及其结果都会保存：被驳回的风险会被保留并计数，而不是被删除；应用建议的进度计划之前会先保存一条基线。批准后的修改属于项目经理，而不是 AI；属于 AI 的是建议，而不是修改。
常见问题
建议区与行动区有什么不同？
行动区的操作会直接修改数据，因为撤消它们成本很低，而且发生频繁（计划草稿、自然语言输入、状态报告初稿、关于项目组合的提问、建议小部件）。建议区的操作会以不易撤消的方式修改已有数据（风险登记册、资源分配、进度计划），因此它们带着证据提出建议，并等待人的接受。同一个 AI 驱动两者；区别在于工具层中的界限。
旁边的证据实际上是什么样子？
在风险提醒中，你会看到它背后的任务：哪些延误或受阻、哪些没有负责人、还剩多少时间。在资源调整中，你会看到被建议人员包含该任务后的那一周：其容量、其余工作，以及加上它后是否超出。在建议的进度计划中，是每个任务建议的开始和完成日期，以及计划将完成的日期。这种模式之所以存在，是因为 AI 对你自己项目的无出处断言，第一次答错就站不住了。
如果我拒绝一条建议会怎样？
它会被驳回，什么都不会改变。驳回会被计数，在风险检测中，计数覆盖你的所有项目：你的团队一再驳回的类别会作为谨慎信号反馈给检测器，只有在项目数据明确支持时才会标出它。它是引导，而不是屏蔽，因此当该类别确实相关时仍然可以出现。
能否扩展建议区，让建议自行应用？
目前不能。建议区的建议始终在等待一个人，没有任何设置能让它们自动执行。不过，做出这个决定所需的证据是存在的：Onplana 记录 AI 建议的接受率，让你看到你的团队对某类建议是几乎总是接受，还是经常修正。如果你的团队对某个特定类型几乎总是接受，请告诉我们，因为这正是值得创建该选项的信号。
排除区里有什么？它也能扩展吗？
那是 AI 不做的决定：财务承诺、基线批准、绩效评估、供应商选择和收尾决定。让它们留在那里的是两件值得区分的事。Onplana 对其中大多数没有相应的功能，所以 AI 没有可以操作的对象。而在存在相关界面的地方，AI 以使用者的权限行事，因此它触及不到那个人手工无法触及的任何东西。原则是：当一个错误的决定会带来撤消按钮无法弥补的法律、财务或个人代价时，AI 不应采取行动。
这就是所谓的“AI 智能体”吗？
这是智能体模式中提议与批准的形式，应用于项目管理工具中的工作。智能体接收证据，准备一项修改建议，连同证据一起展示，并等待人来批准。上面的三种操作是 Onplana 目前提供的自有智能体；随着更多 PMO 流程采用这种形式，还会有更多智能体推出。兼容 MCP 的外部客户端（Claude Desktop、Cursor、你自己的智能体栈）使用同一个界面；连接器页面介绍了它们如何连接。
智能体会从我的修正中学习吗？
在一次对话之内，会：智能体能看到你的拒绝和修改，并调整后续的建议。在对话之间，不会：智能体不会用你的数据进行训练，下一次会话从同样的基本行为开始。在会话之间保留的，是按风险类别统计的驳回次数，它让检测器对你的团队一再拒绝的类别更加谨慎。这是有意为之、可以验证的，而不是模型不透明的漂移。
谁决定哪些外部智能体可以连接？
管理员。把外部 MCP 智能体（Claude Code、Codex、Cursor 等）带进你的组织是一项受管控的操作：一个专门的权限 org.agent.connect 决定谁可以连接智能体，可以排除特定人员或团队、限制每个组织的连接数量，并把任何连接限定在特定项目上，只给它必要的访问权限，这一切都在“人员”区域中完成。撤销一个虚拟人员会立即中断它的访问。关于人与 AI 协作的页面介绍了智能体之后如何作为组织成员参与工作。
另外两个区域
智能体是建议区。行动区（AI 直接修改）以及为两者提供支持的检索层都有各自的页面。
你是在构建集成，而不是管理项目？请查看智能体如何通过 MCP 和 Run-with-Agent 读写计划。