Agentic Information Systems

FLYForeverCC 2026-08-28 13:00:04

Agentic Information Systems：从“被调用的工具”到“可协作的数字代理”

本文根据 Holldack、Banh 和 Strobel 的概念性论文《Agentic information systems》整理，面向希望设计、接入或治理 AI Agent 的工程师和技术管理者。文中的架构、接口和伪代码是基于论文观点做的工程化推演，不代表论文提供了某个可直接安装的框架。

摘要：当 AI 系统能够理解非结构化环境、规划多步任务并自主调用工具时，信息系统的角色会从“被调用的工具”转向“可协作的数字代理”。本文梳理 Agentic IS 的四种形态和三种委托模式，并给出一套包含编排器、工具网关、策略风控和审计的参考架构，最后总结上线前的治理检查项。

关键词：Agentic IS；AI Agent；人机协作；任务委托；权限治理；可观测性

一、为什么要重新理解信息系统

传统信息系统（Information Systems，IS）的基本假设是：人提出目标、调用系统、解释结果并承担最终责任，系统主要负责响应和执行。例如，报表系统返回查询结果，审批系统按照预设规则流转，搜索系统根据关键词返回文档。

生成式 AI、深度学习和多模态模型让系统具备了另一组能力：理解非结构化输入、在不确定性下推理、规划多步任务、调用外部工具、持续观察环境并调整行动。当系统可以围绕长期目标自行选择下一步动作时，它就不再只是一个被动工具，而是一个具有一定行为能动性的数字代理。

论文将这类系统称为 Agentic Information Systems（Agentic IS，代理型信息系统）。这里的“能动性”不是说系统拥有意识或自由意志，而是指它能够在给定约束内，独立承担任务相关的决策与行动，并影响周围环境。

可以用下面的对比快速理解变化：

维度	传统 IS	Agentic IS
任务入口	人工发起、目标明确	可由系统主动发现或持续追踪
输入环境	结构化、边界清晰	非结构化、动态且不确定
决策方式	规则或固定流程	规划、推理、动态选择工具
交互方向	人向系统委托	人与系统双向委托
责任分配	主要归属于人	执行权可转移，但法律责任仍需由组织和人承担
典型角色	工具、模块、服务	助手、队友、监督者或混合单元

关键转变并不是“模型更聪明了”，而是 决策权、行动权和责任边界开始重新分配。这会直接影响系统架构、产品交互和组织治理。

二、Agentic IS 的四种形态

论文给出了一个从低能动性到高协同程度的分类。实际系统可能处于两个类别之间，但这个分类足以帮助我们确定控制方式和风险等级。

1. 辅助型（Assisting）

系统需要人明确发起任务，并在较强的人类指导下完成工作。聊天机器人、语音助手、智能排期、文本和代码生成工具都属于这一类。

主要特征：

人保留目标设定权和最终决策权；
系统对提示词做解释并生成建议或内容；
任务范围和工具权限通常较小；
适合从低风险、可回滚的工作开始引入。

这与今天常见的 Copilot 类产品最接近。即使模型输出质量很高，系统仍然不应默认拥有生产环境写权限。

2. 自主型（Autonomous）

系统可以在较少人工介入的情况下，主动处理复杂、持续时间较长的任务，例如持续监测欺诈、自动驾驶、诊断辅助或自动化交易。

主要特征：

能够主动感知环境并决定下一步动作；
人类从“操作者”变成“监控者”或“例外处理者”；
系统输出可能反过来规定人的任务、时限和优先级；
需要更严格的权限隔离、审计和紧急停止机制。

自主型并不等于“无限授权”。一个合格的自主代理应当只在明确的策略、预算、数据范围和时间窗口内行动。

3. 协作型（Collaborative）

系统作为团队成员与人共同完成目标。双方都可以发起任务、交换上下文、承担子任务，并根据场景动态切换主导权。

例如，在软件开发中，代理负责分析 issue、修改代码和运行测试，人负责澄清需求、审查设计和批准合并。这里的重点不是让代理取代开发者，而是让人和代理形成互补的工作单元。

协作型系统必须解决“谁知道什么”和“谁适合做什么”的问题。代理需要了解自己的能力边界，也需要能够识别何时应把问题升级给人。

4. 混合型（Hybrid）

人和系统高度融合，行动能力在整体层面产生，难以再将每一个决策归因于某个单独实体。增强现实、脑机接口、智能外骨骼以及高度自动化的驾驶/飞行系统可以被视为这一方向的例子。

混合型系统的分析重点从“模型是否正确”转向“人机组合能够完成什么、又会被什么约束”。这要求把接口、组织流程、算法和人的行为放在同一个社会技术系统中评估。

三、三种委托模式：谁发起，谁负责

Agentic IS 的核心机制是 delegation（委托），也就是把任务相关的决策权和行动权在不同代理之间转移。工程实现时，不要只记录“调用了哪个模型”，还要记录“谁在何时把什么权限交给了谁”。

1. 用户发起委托（User-invoked delegation）

人主动把任务交给系统。例如：“读取本周的工单，按优先级归类，并生成处理建议。”

根据监督强度，又可以分成三档：

监督模式	系统行为	适用场景
Human-in-the-loop	每个关键决策执行前都需要人工批准	转账、发布、删除、医疗和合规决策
Human-on-the-loop	系统自主运行，人持续监控并在异常时介入	运营巡检、批量数据处理、自动化测试
无人在环	系统在预先限定的范围内独立完成任务	低风险、可回滚、预算和权限均受控的任务

监督模式不是一次性配置，而应当随风险、置信度、影响范围和系统历史表现动态调整。

2. 双向委托（Bidirectional delegation）

人和系统都可以发起任务，委托所有权会随场景切换。比如，开发者让代理修复缺陷；代理运行测试后发现接口变更风险，再把“确认兼容性策略”的任务交还给开发者。

双向委托有两个工程上容易混淆的层次：

增强（Augmentation）：人和代理是相对独立的同事，显式分配任务、交换结果和审批状态；
组装（Assemblage）：人和代理在某个场景内形成高度一体化的执行单元，委托不一定通过显式命令发生，而是由共享目标、上下文和接口共同驱动。

前者适合企业工作流，后者更接近实时控制或人机协同设备。

3. 系统发起委托（IS-invoked delegation）

系统主动建议把任务交给人或其他代理，甚至直接发起分派。例如，软件工程代理发现需求存在业务歧义，要求产品负责人确认；或者协调代理把数据清洗、检索和代码生成分别分配给不同的专用代理。

系统发起委托又可分为：

弱委托：系统只给出建议，人仍掌握委托所有权；
强委托：系统决定任务领导者、分派对象和完成条件。

强委托能够降低人的认知负担，但会减少人的控制感。因此，强委托必须配套可解释的分派理由、人工接管入口和完整的事件日志。

四、一个可落地的 Agentic IS 参考架构

下面的架构适用于客服、研发、运营和内部知识助手等场景。它刻意把“推理”和“执行”分开，便于限制系统的实际破坏半径。

                 +----------------------+
                 | 用户 / 业务系统       |
                 +----------+-----------+
                            |
                    目标、约束、审批
                            v
                 +----------+-----------+
                 | 代理编排器           |
                 | 规划、状态、委托策略  |
                 +---+------+-------+----+
                     |      |       |
              +------+  +---+---+  +-+---------+
              |记忆/上下文|工具网关|策略与风控 |
              +------+  +---+---+  +-+---------+
                     |      |       |
              +------+  +---+---+  +-+---------+
              |知识库/检索|业务 API |审计与监控 |
              +---------+  +-------+  +---------+
                            |
                     人工审批 / 接管

1. 目标与约束层

把自然语言目标转换成结构化任务对象，至少包含：目标、截止时间、预算、允许使用的数据、允许调用的工具、审批点和失败策略。没有约束的“帮我处理一下”不应直接进入自主执行阶段。

2. 编排器

编排器负责维护任务状态、拆解子任务、选择代理和工具，并决定何时暂停等待人工输入。它不应该把所有逻辑都交给大模型；重试次数、金额上限、目标资源范围等硬约束应由确定性代码执行。

3. 工具网关

所有外部动作都经过统一网关，而不是让模型直接持有业务系统密钥。网关可以实现：

最小权限和短时令牌；
参数校验和数据脱敏；
幂等键、超时、重试和熔断；
高风险操作的二次审批；
调用前后审计记录。

4. 策略与风控层

策略层把风险分数映射到监督模式。例如，读取公开文档可以自动执行；修改生产配置需要人工批准；涉及个人隐私、资金或法律判断的任务必须升级给具备相应权限的人。

5. 审计与可观测性

至少记录 task_id、目标版本、代理版本、输入摘要、工具参数、审批人、策略命中结果、输出摘要、失败原因和最终责任人。日志应支持按任务重放，但要避免把敏感原文无控制地复制到多个系统。

五、最小实现：把委托做成显式状态机

以下伪代码展示一种比“让模型自由调用工具”更容易治理的实现方式。它不是特定厂商 SDK，只用于说明状态和责任如何落在系统中。

from enum import Enum


class State(Enum):
    PLANNED = "planned"
    WAITING_APPROVAL = "waiting_approval"
    RUNNING = "running"
    NEEDS_HUMAN = "needs_human"
    SUCCEEDED = "succeeded"
    FAILED = "failed"


def run_task(task, policy, planner, tools, audit):
    audit.record("task.created", task.id, owner=task.requester)
    plan = planner.make_plan(task.goal, task.context)
    audit.record("plan.created", task.id, steps=plan.public_summary())

    for step in plan.steps:
        decision = policy.evaluate(task, step)

        if decision.requires_approval:
            audit.record("delegation.paused", task.id, reason=decision.reason)
            approval = task.request_approval(step, decision.reason)
            if not approval.granted:
                audit.record("task.rejected", task.id, approver=approval.user)
                return State.FAILED

        if decision.requires_human_input:
            audit.record("delegation.to_human", task.id, step=step.name)
            return State.NEEDS_HUMAN

        result = tools.execute(
            name=step.tool,
            args=decision.sanitized_args,
            idempotency_key=f"{task.id}:{step.index}",
            timeout=decision.timeout,
        )
        audit.record("tool.completed", task.id, step=step.name,
                     status=result.status)

        if result.is_failure:
            return State.FAILED

    audit.record("task.succeeded", task.id, owner=task.accountable_human)
    return State.SUCCEEDED

这个示例有三个值得保留的设计点：

委托发生时有明确事件，而不是隐藏在模型上下文中；
工具参数经过策略层清洗，模型不能绕过权限边界；
即使执行权交给代理，accountable_human 仍然明确存在。

六、四个必须正面解决的挑战

1. 元知识（Metaknowledge）不足

元知识是对“我能做什么、合作方能做什么、当前任务有多复杂”的判断能力。人可能高估模型的可靠性，也可能因为一次失败而完全拒绝系统；代理则需要知道何时自己的信息不足、工具不可用或问题超出能力边界。

可行做法包括：

为每个代理维护能力卡片、适用范围和已知失败模式；
在任务开始前估算不确定性、影响范围和所需权限；
让系统给出“为什么升级给人”的理由，而不是只返回一句失败；
用离线评测和线上反馈持续校准能力声明。

2. 委托、信任与控制的平衡

低信任会让系统无人使用，过度信任则会让人无条件接受错误动作。透明度、可追溯性、人的知识水平、任务是否影响他人，都会改变委托意愿。

不要把“模型置信度”直接当成“业务可信度”。业务可信度还应结合数据新鲜度、工具执行结果、策略风险和历史表现。对高风险动作，应优先采用“系统建议 + 人工确认”，而不是只展示一个百分比。

3. 人本性与技能退化

Agentic IS 的目标不应只是压缩岗位数量。人的同理心、价值判断、非结构化问题处理和责任意识，在临床、司法、管理等场景仍然不可替代。更现实的方向是建设混合型团队：让代理处理规模化检索和执行，让人保留目标、价值权衡和例外处置能力。

如果系统长期替人完成所有认知步骤，人的监督能力会下降，形成“仍由人负责，但人已无法有效检查”的能力缺口。因此必须保留训练模式、抽样复核、人工演练和手动操作通道。

4. 责任与问责

执行权可以由系统持有，但法律责任不会自动转移给软件。组织仍需要明确：谁批准了目标和权限，谁维护了代理和工具，谁在异常时负责接管，谁向受影响的用户解释结果。

建议把问责拆成三层：

层次	要回答的问题
决策责任	谁定义了目标、策略和审批阈值？
执行责任	哪个代理、版本和工具执行了动作？
结果责任	谁对外承担法律、合规和业务后果？

三者可以由不同角色承担，但不能留空，也不能只写“AI 自动完成”。

七、上线前检查清单

任务设计

目标、边界、预算、截止时间和成功标准是否结构化？
是否定义了不可自动化的决策类型？
任务失败、超时、信息不足时是否有升级路径？

权限与数据

每个工具是否使用最小权限和短时凭证？
是否限制代理可读写的数据范围？
是否有防止提示词注入、越权调用和敏感信息泄露的校验？

委托与监督

每次委托是否可被记录、暂停、撤销和重放？
高风险操作是否采用 Human-in-the-loop？
系统主动委托给人时，是否说明了原因和需要的输入？

责任与运营

是否绑定明确的人工责任人和接管时限？
是否保存模型、提示词、策略、工具参数和审批记录的版本？
是否通过抽样复核、红队测试和故障演练验证监督能力？

八、从现有系统迁移的建议路径

不要一开始就建设“全自动员工”。可以按以下顺序推进：

辅助阶段：只读数据、生成建议和草稿，所有外部写操作由人执行；
受控执行阶段：开放低风险、可回滚的工具，并使用 Human-in-the-loop；
协作阶段：让代理能够主动发现问题、提出委托，并把复杂决策升级给人；
有限自主阶段：在明确预算、权限、时间窗口和熔断条件下运行无人值守任务；
系统治理阶段：用组织级指标评估效率、错误率、接管率、技能保持度和责任闭环。

每一步都应有可量化的退出条件。例如，连续若干周期内的误操作率、人工接管响应时间和审计完整率达到阈值后，才允许扩大权限。

九、总结

Agentic Information Systems 代表了信息系统从“响应请求”走向“围绕目标持续行动”的变化。它的技术难点不只在模型推理，还在于如何设计委托、权限、监督和问责。

可以把本文浓缩成三句话：

能力决定系统能做什么，委托决定系统能替谁做决定。
自主执行可以转移操作权，但不能模糊责任边界。
最有价值的落地形态通常是混合团队，而不是无条件替代人。

当我们把代理当作社会技术系统中的参与者，而不仅是一个 API 时，架构设计、产品交互和治理机制才会真正对齐。

参考来源

Holldack, F., Banh, L., & Strobel, G. (2026). Agentic information systems. Electronic Markets, 36, 5. DOI: 10.1007/s12525-025-00861-0。
Baird, A., & Maruping, L. M. (2021). The next generation of research on IS use: A theoretical framework of delegation to and from agentic IS artifacts. MIS Quarterly, 45(1b), 315–341。
European Union. (2024). *Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (EU AI Act)*。